I am curios why the original SIP authors have chosen to use SDP
exchanges to indicate HOLD, instead of defining a "standard" event
package for HOLD?
Regards,
Danail
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Kyzivat
Sent: Thursday, February 16, 2006 4:24 PM
To: Paul Kyzivat
Cc: [email protected]
Subject: Re: [Sip-implementors] Discrepancy with RFC3264 call hold
scenario and RFC4317
Bill kindly pointed out to me that I didn't answer his question.
My revised response to him was:
> Bill,
>
> Sorry. I didn't read your posting carefully and jumped to an improper
conclusion about what you were saying.
>
> Yes, I agree with you that 4317 is in error.
Paul
Paul Kyzivat wrote:
> Bill,
>
> There is a set of rules, which you quote, for what may be in an answer
> depending on what is in the offer. But that does not constrain what
may
> be in a subsequent offer relative to the same stream. E.g.:
>
> 0) A offers sendrecv, B answers sendrecv
> 1) A offers sendonly, B answers recvonly
> 2) B offers inactive, B answers inactive
> 3) A offers sendrecv, B answers sendonly
> 4) B offers sendrecv, A answers sendrecv
>
> In (0) a normal call is established. In (1) A puts the call on hold.
In
> (2) B gets tired of waiting and also puts the call on hold. In (3) A
> tries to take the call off hold and finds out he has been held. In (4)
B
> takes the call off hold so A and B can talk again.
>
> The trick is that each side keeps the state that it *wants* to be in.
It
> puts that into offers. In answers it puts the min(what it wants, what
it
> is permitted based on the offer).
>
> Paul
>
> Bill Moats wrote:
>
>>Hello all, I have been surfing your SIP forum for quite a while and
have
>>found it extremely useful.
>>I hope that you can shed some light on my current call hold problem.
>>I have been implementing a SIP protocol stack using SDP and have run
into
>>problems when dealing with a phone going on hold.
>>
>>RFC3264 Section 6.1 says:
>>"If a stream is offered as sendonly, the corresponding stream MUST be
marked
>>as recvonly or inactive in the answer."
>>
>>RFC3264 Section 8.4 also says:
>>"If the stream to be placed on hold was previously a sendrecv media
stream
>>it is placed on hold by marking it as sendonly. If the stream to be
placed
>>on hold was previously a recvonly media stream, it is placed on hold
by
>>marking it inactive.
>>This means that a stream is placed "on hold" separately in each
>>direction. Each stream is placed "on hold" independently. The
>>recipient of an offer for a stream on-hold SHOULD NOT automatically
>>return an answer with the corresponding stream on hold. An SDP with
>>all streams "on hold" is referred to as held SDP."
>>
>>In my mind, it seems to me that RFC3264 is very clear on how to deal
with
>>ANY offer that is marked a=sendonly.
>>You can 1)set the port to 0 to reject the offer 2) respond with
a=recvonly
>>3) respond with a=inactive.
>>You certainly can NOT respond to a sendonly stream with sendrecv!!!
>>
>>However, if my software responds to a=sendonly with a=recvonly the
phone I
>>have will only continue to offer a=sendonly from that point on.
>>But then I read RFC4317 Section 3.2 which lists an example in which an
offer
>>a=sendonly is responded to with no direction attribute (which implies
>>sendrecv!). The section of interest is below:
>>
>>[Second-Offer]
>>v=0
>>o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
>>s=
>>c=IN IP4 host.biloxi.example.com
>>t=0 0
>>m=audio 49172 RTP/AVP 97
>>a=rtpmap:97 iLBC/8000
>>a=sendonly
>>m=audio 49174 RTP/AVP 98
>>a=rtpmap:98 telephone-event/8000
>>a=recvonly
>>
>>[Second-Answer]
>>v=0
>>o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
>>s=
>>c=IN IP4 host.atlanta.example.com
>>t=0 0
>>m=audio 49170 RTP/AVP 0 97
>>a=rtpmap:0 PCMU/8000
>>a=rtpmap:97 iLBC/8000
>>m=audio 49172 RTP/AVP 98
>>a=rtpmap:98 telephone-event/8000
>>a=sendonly
>>
>>Is this not a violation of the statement from RFC3264 Section 8.4!!!!
Or is
>>there some other mechanism to define why this happens?
>>Is this possibly an error in RFC4317? Is the phone I am using
non-compliant?
>>
>>Any assistance or advice you could give on the subject would be
greatly
>>appreciated!
>>
>>Thanks in advance
>>
>>Bill
>>
>>
>>
>>
>>
>>_______________________________________________
>>Sip-implementors mailing list
>>[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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
