RFC 3261
14.1 UAC Behavior
The same offer-answer model that applies to session descriptions in
INVITEs (Section 13.2.1) applies to re-INVITEs.
So you must provide SDP answer for re-INVITE offer like your code.
It is another issue why pjsip detaching / re-attaching of media transport.
We use external media stream implementation and only do media update when
SDP offer or answer version is changing.
regards,
Gang
On Thu, Jun 25, 2009 at 6:47 PM, Mark Webster
<mark.webster+pjsip at gmail.com<mark.webster%2Bpjsip at gmail.com>
> wrote:
> Hi Gang,
>
> On Thu, Jun 25, 2009 at 5:37 AM, Gang Liu <gangban.lau at gmail.com> wrote:
>
>> Why do you think they breaks RFC? It depents on UA implementation how to
>> handle reInvite.
>> Maybe ask your provider use another keep-alive method like UPDATE without
>> SDP.
>>
>
> They are using re-INVITEs as a hacky kind of keep-alive check, but there
> are no session-expires headers / timers anywhere. As far as I understand it
> (but I'm not a SIP expert yet), re-INVITEs are to be sent when session
> timers are in use, or when the party wants to renegotiate SDP (IP or port
> change, etc).
>
> I'm pretty sure I read somewhere that the remote party (my app) should
> respond with SDP if parameters have changed since the last negotiation. This
> appears to be default behaviour of PJSIP. However, MetaSwitch will hang up
> the call if the 200 OK contains no SDP, which seems completely illogical,
> even if it's not breaking RFC compliance.
>
> In the end I got it working by:
>
> void call_on_rx_offer(pjsip_inv_session *inv, const pjmedia_sdp_session
> *offer) {
> pj_status_t status;
> const pjmedia_sdp_session *active_local;
> pjmedia_sdp_neg_get_active_local(inv->neg, &active_local);
> if (active_local) {
> status = pjsip_inv_set_sdp_answer(inv, active_local);
> }
> }
>
> And then I ignore the subsequent on_media_update, which works for this case
> although I will in future allow detaching / re-attaching of media transport
> to support any SDP changes.
>
> I welcome any information regarding what the RFCs say about this case!
>
> Many thanks,
> -Mark
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090626/9ea0b899/attachment.html>
