Hello again,
Thanks for the response.
An Wed, Apr 02, 2008, Benny Prijono schrieb:
>On Tue, Apr 1, 2008 at 10:18 PM, Michael CHRISTOPHER wrote:
>> [...]
>> I'm wondering if its worth the effort to port portaudio to
>> gstreamer (without OSS/ALSA) and debug the TCP transport. The
>> registrar problem could be easier, namely...
>
>No OSS/ALSA? Sounds like trouble indeed. Rather than porting
>PortAudio, I think it would be lot easier to create a sound device
>abstraction for pjmedia. The API is whole lot simpler, and there is a
>ready to use template for new implementation (namely nullsound.c).
>
Although it appeals to have portaudio for other projects as well,
I'll look into abandoning it and developing nullsound.c instead.
With some luck I'll have a gstreamified audio device when finished.
>> REGISTER: If a registrar successfully saves the AOR of pjsua(1) and
>> returns the expiry value in the 'Contact' header, pjsua(1) believes
>> that the registration failed, indicating an expiry of -1 in the UI.
>> It seems that pjsua(1) insists on seeing a separate 'Expiry' header.
>> The registrar I used to test this was OpenSER 1.3.1-tls.
>
>I don't think that's the reason why pjsip thinks that the registration
>had failed. Probably what happened is the server returned modified
>Contact header than what pjsua had put in the request, and pjsip
>thinks that the registration had failed because it couldn't find its
>Contact header there. Maybe there is a configuration in OpenSER that
>you use that modifies the Contact header (it's probably got something
>to do with NAT, but couldn't remember the exact configuration name for
>it).
>
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?
By the way, pjsip thinks the registration fails in regc_cb() of:
pjsip/src/pjsua-lib/pjsua_acc.c:863:
if (param->expiration < 1) { *** <-- HERE! ***
pjsip_regc_destroy(acc->regc);
acc->regc = NULL;
I was unable to understand how regc_cb() is called or why the
expiration value from the 'Contact' header (600 in my case) is
not used. It's hard to believe that even on successful registrations
pjsua rejects the returned 'Contact' header completely. If that's
indeed the case, and unless there's a good reason not to, I might
patch that rejection logic to correctly set the expiration value.
Sadly, I can't find the place where such 'Contact' header parsing
occurs. I looked at [1] trying to trace this logic, but it seems
that callbacks are not documented (?) or maybe the docs are not in
sync with the SVN tree (?). Am I going about this porting wrongly?
Regards,
Michael
[1] http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__ACC.htm
