Jump to content

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


Archana Rao
 Share

Recommended Posts

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

Link to comment
Share on other sites

[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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...