2010/4/21 Jin-Soo Eo :
> Dear Implementors ,
>
> Hello All,
> I have a question about the charset parameter rule of Content-tpye header.
>
> If Content-type header of INVITE includes utf-8 charset parameter,
> same charset value is provided in Content-Type header of 200 OK response?
>
> The followi
Iñaki Baz Castillo - Thank you so much!!!
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Wednesday, April 21, 2010 7:04 PM
To: Nahum Nir
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Please Help With that ACK
2010/4/21 Nahum Nir :
>
2010/4/21 Paul Kyzivat :
> Rather that considering it "hyper-exotic and unfeasible", you could just
> consider it "forward looking".
Yes, I understant. However under my experience "forward looking"
features of IETF are "hyper-exotic and unfeasible" features in the
real world.
Let's wait 10 years t
2010/4/21 Nahum Nir :
> I got mixed with the logs files, sorry. It has the same call-id to-tag and
> from-tag:
The trace you show below has still different Call-ID and From/To tags.
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP
> 192.168.2.100:5060;branch=z9hG4bk02mhgcym10j528rrd3xqc79376zgk1682;rec
I got mixed with the logs files, sorry. It has the same call-id to-tag and
from-tag:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.2.100:5060;branch=z9hG4bk02mhgcym10j528rrd3xqc79376zgk1682;received=89.138.192.6;rport=45000
From: ;tag=4apfgokuahrswy8cl2skl0e6if0d47zdwqbw3mtx
To: ;tag=as73f5b3e0
C
2010/4/21 Nahum Nir :
> Thanks to Iñaki Baz Castillo and Brett Tate (and to all others that replied).
> I am now generating a new branch and it is still get disconnected:
Of course! the ACK for the INVITE has a different Call-ID, From-tag
and To-tag!! what is it?
--
Iñaki Baz Castillo
__
Thanks to Iñaki Baz Castillo and Brett Tate (and to all others that replied). I
am now generating a new branch and it is still get disconnected:
INVITE sip:1...@81.218.154.62 SIP/2.0
Via: SIP/2.0/UDP
192.168.2.100:5060;rport;branch=z9hG4bk02mhgcym10j528rrd3xqc79376zgk1682
Max-Forwards: 70
Fro
2010/4/21 Brett Tate :
>> Well, this is basically because the ACK for a 200 is a new
>> transaction (as it is end-to-end rather than hop-by-hop as
>> the ACK for a negative final response).
>> How could it be in other way?
>
> I agree that it was the justification used (and it can be helpful to som
> How could it be in other way? Perhaps a valid question is: why does
> the ACK for a 200 mantain the same CSeq as the INVITE?
Probably to match the INVITE being acked. This might help in the
determining the offer-answer correlation.
Hope my reasoning is correct!
On Wed, Apr 21, 2010 at 8:18 PM,
> > It is one of the infamous gotchas within rfc3261. I won't
> > bother to try explaining why some think such strangeness
> > is desirable.
>
> Well, this is basically because the ACK for a 200 is a new
> transaction (as it is end-to-end rather than hop-by-hop as
> the ACK for a negative fin
2010/4/21 Brett Tate :
> Your ACK via branch is incorrect for acking an INVITE 2xx response. Yours
> matches the INVITE. This is correct when acking non-2xx; it is not correct
> when acking a 2xx. It needs a new transaction ID per the magic cookie rules;
> thus you need new via branch.
>
> It
Your ACK via branch is incorrect for acking an INVITE 2xx response. Yours
matches the INVITE. This is correct when acking non-2xx; it is not correct
when acking a 2xx. It needs a new transaction ID per the magic cookie rules;
thus you need new via branch.
It is one of the infamous gotchas wi
Hi All,
My call is getting disconnected after 30 seconds so I guess that there is
something wrong with my ack.
Please take a look at the dialog below and tell me what is the problem.
Thanks,
Nahum
INVITE sip:1...@81.218.154.62 SIP/2.0
Via: SIP/2.0/UDP
192.168.2.100:5060;r
Iñaki,
Iñaki Baz Castillo wrote:
> 2010/4/20 Brett Tate :
>> section 5.1.1.1:
>> " If all the Contact header fields in a REGISTER request are SIPS, the
>> UAC MUST use SIPS AORs in the From and To header fields in the
>> REGISTER request. If at least one of the Contact header fields is
>>
> If in the request URI "transport" parameter was set as "tcp",
> should this need to alter the VIA header also
> " Via: SIP/2.0/TCP proxy.domain.com". ???
No; the request's first/top via entry's transport must match the used
transport. If request is sent using UDP, the via transport must be U
It depends upon how forgiving you want to be and can be. Yes; you can discard
the response. If decided to treat it as valid, you'd need to decide if your
ACK should include the invalid cseq number or valid cseq number.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.colu
As per RFC 3261, the transaction match parameters are
Via branch parameter and Cseq METHOD.
So there is no necessity that an UA receiving a response validates the
Cseq number, though it is not incorrect.
On Wed, Apr 21, 2010 at 5:47 PM, kanthu canty wrote:
> Here I am with doubt...
>
> What
Here I am with doubt...
What do I need to do If the cseq number of 200ok response is unmatched
with the INVITE request Do I
need to discord that response or not
Disording the responses on the basis of cseq number is right???
--
Cheers
Kanthu(Canty)
kanthu.ca...@gmail.com
_
Dear Implementors ,
Hello All,
I have a question about the charset parameter rule of Content-tpye header.
If Content-type header of INVITE includes utf-8 charset parameter,
same charset value is provided in Content-Type header of 200 OK response?
The following case is invalid?
INVITE
Content-
It isn't a joke; however the following April 1 draft is most excellent:
http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt
I'm not sure if anyone uses the "hyper-exotic and unfeasible feature"; however
RFC 3261 does allow registering and redirecting to such contact URIs.
> -Original
20 matches
Mail list logo
