I don't claim to be the one who chose this direction. But in reality
there is nothing that is explicitly for hold. The directionality
attributes are useful for many purposes. It happens that they are useful
for hold as well. (You cannot accurately construe that because you have
been offered sendonly you must have been put on hold.
Another answer is that this was defined before the event mechanism was
defined.
Paul
Danail Kirov wrote:
> 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
