Sofia-SIP

Hi,

some updates and a cleaner scenario.

same issue appears in the following scenario

local                       remote
      invite ->
   <- 183 Session Progress
      prack ->
   <- ok
   <- update
      ok    ->
   <- 183 Session Progress (same callid, different to_tag, so new dialog)
   <- 183 Session Progress 
   <- 183 Session Progress 
... unitil we get a gateway timeout ...

basically remote is a b2bua which does a call transfer by issuing
an update to local and then sending a progress while remote_2 is ringing.

The different thing is that on second 183 the to_tag is different,
since is a different dialog.

Placing some debug into nta.c, agent_recv_response, after found outgoing 
I notice that first 183 had orq->orq_destroyed == 0, next 183s have
orq->orq_destroyed == 1 , so get not handled after...

any hint?

regards,
matteo.

Hi,

I've recreated the scenario using sipp, if someone is interested, it can be found
here: http://pastebin.ca/2057979

in the attached sipp scenario, nua fails responding with prack
to latest 183 Session Progress, where the dialog has changed.
(different to_tag).

regards,
matteo.

Hi,

going on with debug, the issue is that outgoing_find does not
check for different to_tag in provisional response.

I've created a patch that "works for me" which
handles different to_tag in provisional responses and
manage RSeq in right way if to_tag changed.

but I don't know if this is the proper way to do it.

open to better ideas.

regards,
matteo.

Hi Matteo,

2011/5/17 Matteo <mbrancaleoni@...>:
> going on with debug, the issue is that outgoing_find does not
> check for different to_tag in provisional response.
>
> I've created a patch that "works for me" which
> handles different to_tag in provisional responses and
> manage RSeq in right way if to_tag changed.
>
> but I don't know if this is the proper way to do it.

The early dialog and especially early media with forking is, indeed,
tricky.  There was some talk with Anthony M. on media handling in that
case, but we got never around to define how the media should behave.
(Should the early media from all forks be played? Should they be
mixed? If a 200 OK is received from another fork, how it should be
handled?)

Currently, I think, nua on FreeSwitch sticks to first fork sending it
a 100rel response as you noticed.

My original idea was to handle each fork (especially with reliable 1xx
responses) in a separate nua handle and let the application (in this
case FreeSwitch) to handle all the hairiness related to media, but
perhaps there is a cleaner approach.

-- 
Pekka.Pessi mail at nokia.com

Hi,

----- Messaggio originale -----

> The early dialog and especially early media with forking is, indeed,
> tricky.  There was some talk with Anthony M. on media handling in
> that
> case, but we got never around to define how the media should behave.
> (Should the early media from all forks be played? Should they be
> mixed? If a 200 OK is received from another fork, how it should be
> handled?)

In the scenario that I'm facing there's always an UPDATE that simply
tells to stop the media, by setting the sdp as inactive,
before sending another 183 with media.
So there's no overlap in this case.

> My original idea was to handle each fork (especially with reliable
> 1xx
> responses) in a separate nua handle and let the application (in this
> case FreeSwitch) to handle all the hairiness related to media, but
> perhaps there is a cleaner approach.

I agree, in that way my patch is totally wrong, also it's not sending
the correct to_tag when pracking forked dialog.

matteo.