An Wed, Apr 02, 2008, Michael CHRISTOPHER schrieb:
>An Wed, Apr 02, 2008, Benny PRIJONO schrieb:
>>On Wed, Apr 2, 2008 at 10:07 AM, Michael CHRISTOPHER wrote:
>>>I assume all registrars with NAT correction logic will return a
>>>'Contact' header differing from that of a NATted UAs 'REGISTER'
>>>request. Is it intentional that the pjsip component rejects this?
>>>
>>Yes, since it's in my understanding that registrar should never ever
>>modify the Contact header according to RFC 3261, regardless on how it
>>thinks it may help with NAT. Unfortunately many registrars out there
>>violate this, either misconfigured (with (Open)SER case) or just plain
>>broken.
>>
>>[...]
>>
>>It's for the reasons above. I would say it'll be better to fix your
>>server config though (e.g. use fix_nated_register() rather than
>>fix_nated_contact()).
>>
>I've got both fix_nated_register() and fix_nated_contact(), so I'll
>experiment removing the fix_nated_contact() as you recommend.
>
Well, I'm glad to report that the fix was easy. When correcting for
NATed 'REGISTER' messages, don't use fix_nated_contact() at all. Use
fix_nated_register() instead, as Benny suggested in a post to this
thread.
For good measure, here's what my testing yielded. The pjsua UA sends
the OpenSER registrar a 'REGISTER' message. On a Nokia 770 tablet, the
pjsua UI will reflect the successful registration with:
Account list:
[ 0] <sip:192.168.0.11:5060>: does not register
Online status: Online
[ 1] <sip:192.168.0.11:5060;transport=TCP>: does not register
Online status: Online
[ 2] <sip:192.168.0.11:5061>: does not register
Online status: Online
*[ 3] sips:maemotest at myserhost.tld: 200/OK (expires=588)
Online status: Online
The above is configuration specific, of course. I'm using TLS as the
transport, and in my config file are:
--id sips:maemotest at myserhost.tld
--proxy sips:myserhost.tld:5061;transport=tls;lr
--registrar sips:myserhost.tld;transport=tls
After the succesfull registration, a OpenSER registrar responds to
the command 'openserctl ul show' with something like:
AOR:: maemotest
Contact:: sips:maemotest at 192.168.0.11:5061 Q=
Expires:: 417
Callid:: j.GbwbkphQ4CizcMXJwpY9k1xpKmhzml
Cseq:: 32363
User-agent:: PJSUA v0.8.0-trunk/i486-pc-linux-gnu
Received:: sip:***.***.***.***:81530;transport=TLS
State:: CS_SYNC
Flags:: 0
Cflag:: 64
Socket:: tls:***.***.***.***:5061
Methods:: 4294967295
The 'Received' line is appended by the OpenSER Nathelper module
function called fix_nated_register(), which will appear as well
in the 'Contact' header returned to the UA during registration.
----
Now on to discovering what's causing the following error at
every single 'INVITE' that pjsua receives:
pjsua: ../src/pjmedia/transport_srtp.c:563: transport_get_info:
Assertion `info->specific_info_cnt < 4' failed.
Killed
The other UA issuing the 'INVITE' through OpenSER is a Snom
hardphone with latest firmware. The Twinkle softphone does no
better. The 'SDP' header arriving at the pjsua UAS looks like:
v=0
o=root 1741664190 1741664190 IN IP4 192.168.0.55
s=call
c=IN IP4 128.821.128.821
t=0 0
m=audio 35701 RTP/AVP 9 8 0 2 18 3 4 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:Qz80xwZhJmItcmsY3oGJmkBuBArCm7ydMlsLz9CM
a=rtpmap:9 g722/8000
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:2 g726-32/8000
a=rtpmap:18 g729/8000
a=rtpmap:3 gsm/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=encryption:optional
a=alt:1 1.0 : user 9kksj== 128.821.128.821 35701
a=alt:2 0.9 : user 9kksj== 192.168.0.55 70242
a=sendrecv
a=direction:active
a=oldmediaip:192.168.0.55
Not sure why the Snom is sending RTP/AVP and not RTP/SAVP as
is standard for SRTP, but that's not the problem anyway. If I
disactivate SRTP in both the Snom UA and pjsua UA and transmit
clear RTP, the same failure occurs.
Any ideas? Is SRTP even stable enough to deem such testing worthy?
Regards,
Michael
