I agree with Paul here,
Actually the 200(CANCEL) just means the proxy got the CANCEL,
It does not mean the request is cancelled or proxy would be ensure the req
being cancelled.
Normally, Proxy would send the CANCEL downstream, however, since there's no
provisional resp,
Proxy has no means to co
I don't understand why stateless forwarding has been mentioned in the
context of this question. AFAIK it has no relevance.
If we assume that the pcscf in the question is a transaction stateful
proxy (and I'm pretty certain that any IMS implementation would be),
then when the 200 INVITE is recei
On Thu, 2008-12-18 at 21:15 +, Eduardo Martins wrote:
> The problem is that without knowing if the uri is a resource list or
> not, the subscribe request should not considered valid (the 202
> response implies it is valid), since the Accept (must support
> multipart and rlmi) and Supported (mus
On Mon, 2008-12-22 at 21:25 +0530, Pankaj Munjal wrote:
> Is there any other draft/RFC that governs the set of possible values that
> "Content-Disposition" header can hold,
> or this field can be used based on Application implementation?
The set of valid values can change as new values are standar
Hello Everyone,
Section 5.10 of RFC 4483 states:
A Content-Disposition entity header MUST be present for all indirect
content.
For example:
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="h
2008/12/22 Maxim Sobolev :
>> Alto consider the following draft:
>> http://tools.ietf.org/html/draft-sparks-sip-invfix-02
>>
>> It states that a transaction statefull proxy mustn't forward a 200
>> stateless, so in your case the 200 OK wouldn't arrive to the UAC (if
>> the proxy honors the above
Iñaki Baz Castillo wrote:
> 2008/12/22 karthik karthik :
>> step3.
>> meanwhile the callee has sent 200(invite) without 18x directly.
>> ue<--200(invite)--pcscf<--200(invite)--scscf<--200(invite)--
>> ue--ack-->pcscf--ack-->scscf--ack-->
>> ue sends an ack though it had already sent a cancel.
>>
>>
2008/12/22 karthik karthik :
> step3.
> meanwhile the callee has sent 200(invite) without 18x directly.
> ue<--200(invite)--pcscf<--200(invite)--scscf<--200(invite)--
> ue--ack-->pcscf--ack-->scscf--ack-->
> ue sends an ack though it had already sent a cancel.
>
> what is the expected bahaviour at
Hello Karthik,
UAC wanted to terminate the session but before its CANCEL request reached
UAS , uas accepted the INVITE. This is a valid scenario and its handling
purely depends on UAC's programming.
1. It can render this "call connect" to USER
or
2. After receiving 200 Ok could generate BYE w
