[SIPForum-discussion] need help from people who know all the rules by heart
Michael Trank
mtrank at apexvoice.com
Tue Apr 21 01:45:42 UTC 2009
Hi Nitin:
It was my code that produced and sent the BlackHole SDP.
My problem was that the other UA would sometimes send a BYE before
processing the Re-INVITE, and then would never respond to the re-INVITE.
The stack I am using was also getting stuck after getting the BYE when
expecting a response to the re-INVITE.
So I had a situation where the two UA's were kind of locking up and
never properly clearing out the call stuctures in my program.
My question was really about what is "supposed" to happen in a case like
that, and apparently the answer is that UA's are permitted to send a BYE
even when a re-INVITE transaction has been started. This meant that *my*
side ( my program and SIP stack ) *needed* to process the BYE, even
though I had just sent a re-INVITE, according to the rules. So I set
about finding out how to fix that, and found a work-around in the way I
called the stack functions so that it would process the BYE during the
re-INVITE transaction.
The UA on the other end still doesn't respond to the re-INVITE, which I
think the are supposed to, but as long as my side processes the BYE and
responds, everything works OK.
nitin kapoor wrote:
> Hello Michael,
>
>
>
> Black hole can be possible in some case(eg: where you are going to put
> your call on hold).
>
>
>
> Especially on those cases, where first party is sending you OFFER
> contains an audio stream, but the answer from the other contains the
> connection address 0.0.0.0 and a random port number, which means that
> first party cannot send media to second party (the media stream is
> "black holed" or "bh"). In the second exchange, second party changes
> the connection address, and the first party can accepts, and a media
> session is established.
>
>
> Can you please send the ethereal traces so that we can check.
>
>
>
> Thanks,
>
> Nitin Kapoor
>
>
>
> 2009/4/17 RAJESH KUMAR RAJU <rajeshk.r at samsung.com
> <mailto:rajeshk.r at samsung.com>>
>
>
> HI ,
>
> what is Black hole SDP and kindly attach eth trace without this
> difficult to trace
>
>
>
>
>
> ------- *Original Message* -------
> *Sender* : Michael Trank<mtrank at apexvoice.com
> <mailto:mtrank at apexvoice.com>>
> *Date* : Apr 17, 2009 11:56 (GMT+09:00)
> *Title* : [SIPForum-discussion] need help from people who know all
> the rules by heart
>
>
> I have a situation where some sessions between a UAC and a UAS look like
>
> this:
>
> It looks like this:
>
> UAC UAS
>
> INVITE ===>>
> 200 OK <<===
> ACK ===>>
>
> some seconds pass by....
>
> Re-INVITE <<==== ( with "BlackHole" SDP )
> 100 Trying ===>
> BYE ===>
> 100 Trying <=== ( provisional for BYE )
> BYE ===>
> 100 Trying <=== ( provisional for BYE )
> BYE ===>
> 100 Trying <=== ( provisional for BYE )
> BYE ===>
> 100 Trying <=== ( provisional for BYE )
> BYE ===>
> 100 Trying <=== ( provisional for BYE )
>
>
> and thats it, things kind of get stuck like this. The BYE's stop, but
>
> the call finished somewhat un-gracefully.
>
> What is supposed to happen when a re-INVITE gets sent in one
> direction and a BYE gets sent in the other, ignoring the re-INVITE?
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
>
> Post to the list at discussion at sipforum.org
> <mailto:discussion at sipforum.org>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
> <mailto:discussion at sipforum.org>
>
>
More information about the discussion
mailing list