Pbxnsip v2.0 - Issues in the contact header and payload type

[Archana Rao]

Hello,

While using Pbxnsip version 2.0, I found the following -

 

[1] I have a simple setup with Pbxnsip with two extensions registered. The scenario I'm testing is when the extension sip:201@pbxnsip.domain sends an INVITE to the other extension sip:202@pbxnsip.domain. The problem is that the INVITE received by 202 (when 201 calls it) has URI <sip:202@128.59.20.93:5060> in the contact header. This is wrong as the URI should be the URI of 201, not the one of 202. Have I configured Pbxnsip wrongly? Has anyone else seen the same/similar behavior?

 

[2] Pbxnsip puts the payload type 2 for a dynamic codec (G726-32/8000). Since payload types 1 and 2 are reserved as per IANA documentation, isn't this a non-standard practice?

 

I've attached a log snippet as captured at the extension 202.

 

Any suggestions are helpful.

 

Sincerely,

Archana.

 

22:08:22 UDP Packet Received from 128.59.20.93:5060 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
INVITE sip:202@128.59.19.235:5070 SIP/2.0
Via: SIP/2.0/UDP 128.59.20.93:5060;branch=z9hG4bK-bb582c3d621e07a66837de4c4e45a16f;rport
From: "Grandstream " <sip:201@pbxnsip.domain>;tag=54011
To: "DLink " <sip:202@pbxnsip.domain>
Call-ID: 11ae4701@pbx
CSeq: 7970 INVITE
Max-Forwards: 70
Contact: <sip:202@128.59.20.93:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO, PUBLISH, NOTIFY, SUBSCRIBE, MESSAGE
Accept: application/sdp
User-Agent: pbxnsip-PBX/2.0.0.1613
Alert-Info: <http://127.0.0.1/Bellcore-dr2>
Content-Type: application/sdp
Content-Length: 266

v=0
o=- 41903 41903 IN IP4 128.59.20.93
s=-
c=IN IP4 128.59.20.93
t=0 0
m=audio 59002 RTP/AVP 0 8 2 3 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:2 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=sendrecv

[Vodia PBX]

[1] The problem is that the INVITE received by 202 (when 201 calls it) has URI <sip:202@128.59.20.93:5060> in the contact header. This is wrong as the URI should be the URI of 201, not the one of 202. Have I configured Pbxnsip wrongly?

Don't worry about that. Once the dialog is established, a user-agent can use whatever contact it likes - the PBX identifies the contact by its Call-ID. The PBX is not a proxy, therefore the routing information is not important.

 

The contact was set this way because there is a large ITSP in America that insisted on this style...

 

[2] Pbxnsip puts the payload type 2 for a dynamic codec (G726-32/8000). Since payload types 1 and 2 are reserved as per IANA documentation, isn't this a non-standard practice?

 

There are two styles for G726. On is the "IETF" way the other the "ITU" way. They could not agree on the same bit nibble format or so. The IETF has defined a RTP packet load type, but it seems that is very confusing and can easily lead to misunderstandings. Here I do see room for improvement from the pbxnsip side.