2009/1/9 Bernhard Suttner <bernhard.sutt...@comdasys.com>:
> Step 3
> SIP Client send a ReINVITE with "a=inactive"
> B responses with 488 (Not acceptable here)
> SIP Client ACK's
>
> Step 4
> B send a ReINVITE with "a=sendrecv"
> SIP Client accepts this with "a=inactive" <-- WHY???
> B ACK's
>
> In my opinion the mistake is in Step 3. The SIP Client want to set the
> session to a=inactive but the Server does reject this. Now the SIP Stack
> should re-set the state and should not save the "a=inactive" which it
> will sadly use in Step 4. To fix that "by hand" I have added a short
> section in the SIP Client in the "nua_r_invite":
>
> nua_set_hparams(nh, SOATAG_HOLD(""), TAG_END());
>
> What do you think? Is that a bug in the SIP Stack or is that a task
> which has to be done in the SIP Client (and not in the stack)?
Your app give NUA or SOA a desired target state for the media ("user
sdp" plus some tags in nua_invite()) which is tries to reach. When you
get 488, there is two possible approaches: stack reverts back to
previous target or the stack changes the target. Currently, stack does
not keep track of the previous target but flushes it immediately when
the nua_invite() is called. While it is perfectly possible to track
the previous state, that would require much more work.
I'd go for the option B, let the SIP client modify the target again
like you already do w/ nua_set_hparams().
--
Pekka.Pessi mail at nokia.com
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
