On 3/8/12 5:05 PM, Sajeewa Don wrote:
> Thank you for your replies.
> One particular scenario I'm trying to understand is why in some
> occasions we see sip re-invite before the termination of a call.
>
>
> Below is an example,
>
> SIP reinvites at the very end of a call (before terminate) with sdp
> ""sendonly", and respond from the other party 200 OK with sdp "recieveonly"
This behavior may seem odd to you. But presumably the other end thinks
it has a reason for it, whether it is a good one or not. If you really
want to know, and you know who makes that device, you could always ask.
But its probably not worthwhile to speculate. There is nothing *wrong*
with what you are showing. So my advice is to just accept it.
Thanks,
Paul
> CALL FLOW DIAGRAM
>
>
>
> |36602.618| INVITE SDP (g711A g711U g729 g721
> telephone-ev...RTPType-101) |SIP From: <sip:[email protected]
> To:<sip:[email protected]
> | |(5060) ------------------> (5060) |
> |36602.619| 100 Trying| |SIP Status
> | |(5060) <------------------ (5060) |
> |36603.055| RTP (g711A) |RTP Num packets:2466
> Duration:49.299s SSRC:0x68BDE27D
> | |(1024) <------------------ (18148) |
> |36603.082| 183 Session Progress SDP (g711A
> telephone-even...PType-101) |SIP Status
> | |(5060) <------------------ (5060) |
> |36603.366| RTP (g711A) |RTP Num packets:174
> Duration:3.458s SSRC:0x4505ED2C
> | |(1024) ------------------> (18148) |
> |36606.840| 200 OK SDP (g711A
> telephone-eventRTPType-101) |SIP Status
> | |(5060) <------------------ (5060) |
> |36606.845| RTP (g711A) |RTP Num packets:2275
> Duration:45.480s SSRC:0x4505ED2C
> | |(1024) ------------------> (18148) |
> |36606.870| ACK | |SIP Request
> | |(5060) ------------------> (5060) |
> |36652.342| INVITE SDP (g711A
> telephone-eventRTPType-101) |SIP Request
> | |(5060) <------------------ (5060) |
> |36652.346| RTP (g711A) |RTP Num packets:4
> Duration:0.056s SSRC:0x4505ED2C
> | |(1024) ------------------> (18148) |
> |36652.359| 200 Ok SDP (g711A
> telephone-eventRTPType-101) |SIP Status
> | |(5060) ------------------> (5060) |
> |36652.375| RTP (g711A) |RTP Num packets:22
> Duration:0.420s SSRC:0x68BDE27D
> | |(1024) <------------------ (18148) |
> |36652.410| ACK | |SIP Request
> | |(5060) <------------------ (5060) |
> |36652.879| BYE | |SIP Request
> | |(5060) <------------------ (5060) |
> |36652.891| 200 Ok | |SIP Status
> | |(5060) ------------------> (5060) |
>
> Thanks,
>
> Sajeewa
>
>
> On Fri, Mar 9, 2012 at 4:22 AM, Paul Kyzivat <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 3/8/12 8:32 AM, Kevin P. Fleming wrote:
> > On 03/07/2012 07:01 PM, Sajeewa Don wrote:
> >> I would like to understand different possible SIP REINVITE
> Scenarios.
> >>> From my knowledge there are three occasions where reinvite
> could occur,
> >>
> >> Scenario 1 - To make a Call On Hold by sending a reinvite with
> >> sendonly/recieveonly
> >> Scenario 2 - To change parameters of the original connecting
> information
> >> Scenario 3 - Allows periodic refresh of the SIP sessions through
> re-INVITE
> >>
> >> Is there any other possibile Reinvite scenarios?
> >>
> >> If you could share your knowledge on this that would be great.
> >
> > There are probably an infinite number of scenarios in which a
> re-INVITE
> > could be issued. What do you believe is the value of trying to
> identify
> > all possible reasons that you might receive a re-INVITE?
>
> I agree.
>
> To the original poster:
>
> Is the goal to for the UAS to figure out *why* a particular reinvite was
> sent?
>
> That is a fools errand. You in general can't, and shouldn't try to,
> know. Your behavior to a reinvite should not be based on knowing *why*,
> it should simply respond to what is being proposed, in the context of
> your current knowledge of your own state and policies.
>
> For instance, a reinvite w/sendonly is not necessarily an indication
> that the other end is putting the call on hold. All you know is that you
> aren't allowed to send media to it. Also, once there is more than one
> m-line in the call (e.g. audio & video) then they may have inconsistent
> selections for sendrecv/..., so its hard to classify the call itself as
> held or not. (I suggest you look at RFC6337. Take special note of
> section 5.)
>
> Also, every reinvite, whatever else it changes or does not change,
> serves as a reset or refresh of session timer. This is true whether it
> is periodic or not.
>
> And don't forget reinvites with no offer. You need to support them too,
> in spite of now having a clue of why you received it.
>
> Good Luck,
> Paul
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
