[pjsip] Porting to Maemo

Michael CHRISTOPHER pjsip at encambio.com
Wed Apr 2 10:13:09 EDT 2008


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




More information about the pjsip mailing list