Hi
There are parameters which are SIP Header specific. For example:
to-param= tag-param / generic-param
from-param = tag-param / generic-param
info-param = ( "purpose" EQUAL ( "icon" / "info"
/ "card" / token ) ) / generic-param
auth-param = auth-param-name EQUAL
Hi folks,
RFC3261
16.6 Request Forwarding
2. Request-URI
The Request-URI in the copy's start line MUST be replaced with
the URI for this target. If the URI contains any parameters
not allowed in a Request-URI, they MUST be removed.
But I don't see which param
It is widely (universally) used in 3GPP/IMS.
In there architecture, the UA connects to an edge proxy/b2bua (the
P-CSCF), and this eventually sends the request to the originating user's
home proxy/b2bua (S-CSCF). The registration is handled by the S-CSCF,
and the P-CSCF notes this as proof of ide
Hi,
CANCEL is a hop-by-hop req, the to tag is used to
identify the UAS that is responding,
So if CANCEL passes through a stateful proxy ,
the to tag of 200(CANCEL) and final response for cancelled req are
Probably different.
Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:
Brett,
I think you're correct, this is another inconsistence.
Actually, I am quite confused here, why 3261 does not allow remote
target get updated here, Record-Route can get updated, I do NOT see any
reason remote target cannot.
Thanks
-Rockson
-Original Message-
From: [EMAIL PROTECT
Hi, is there in the real life any usage of P-Asserted-Identity other than
indicating a PSTN gateway the callerid?
Please, I mean *real* usage, don't suggest me dream and exotic escenarios
written in a draft or RFC that nobody will never implement.
Thanks a lot.
--
Iñaki Baz Castillo
Hi, when a UAS receives a CANCEL it must generate a 200 OK for that CANCEL
with the same "To tag" that te one in the 487 that terminates the INVITE
transaction.
But when a proxy receives a CANCEL the "To tag" in the 200 OK mustn't match
the "To tag" in the 487.
Since CANCEL is matched as tran
El Miércoles, 20 de Agosto de 2008, Brett Tate escribió:
> Thanks for the response.
>
> The following is the basis for the conflict: "the route set for the
> dialog MUST be recomputed based on the 2xx response using the procedures
> of Section 12.2.1.2."
>
> The procedure of section 12.2.1.2 does n
From: Sudhir Kumar Reddy <[EMAIL PROTECTED]>
Can I know what is significance of X-Route-Tag parameter in Via Header?
The "X-" part means that it is a non-standardized parameter name.
What device is adding this parameter?
Dale
___
Sip-implementor
Hi Paul,
I think your suggestion of including the value in Allow header only if
it's received from other side, is the best solution considering the
following constraints:
1) Since the call is in early dialog, translating the UPDATE to Re-INVITE on
the other leg would result in failure of the U
Thanks for the response.
The following is the basis for the conflict: "the route set for the
dialog MUST be recomputed based on the 2xx response using the procedures
of Section 12.2.1.2."
The procedure of section 12.2.1.2 does not recompute the route set
(except for the remote target URI).
> --
I do not think Paragraph 3 conflicts paragraph 2. Both are saying same
thing about route set, in that, it needs to be recomputed when 2xx is
received, because, as you also point out, rfc 2543 did not mandate
echoing RR headers in 1xx responses.
Paragraph 3 is about updating other dialog states and
RFC 3261 section 13.2.2.4 discusses the impacts of INVITE 2xx when a
dialog known because prior 1xx.
Paragraph 3 appears to conflict with paragraph 2 concerning updating the
route set. Paragraph 2 indicates that the route set must be recomputed
per 12.2.1.2 (which updates the remote-target withou
Well, I can find nothing that formally says 1xx excludes 100, and in
fact do find the contrary. However there are places in 3261 that give
rules for 1xx that in fact don't apply to 100. So be careful when 1xx is
used.
Paul
Attila Sipos wrote:
> AFAIK, 100 is a 1xx response but it diffe
I agree that 100 is unique within 1xx; however 1xx does include 100 (although
some indicate 1xx when they really mean 101-199).
RFC 3261 section 7.2: "For this reason, any response with a status code between
100 and 199 is referred to as a "1xx response","
> -Original Message-
> From:
An hop-by-hop reply makes sense only in stateful mode, but in stateless
mode 100 will behave as the rest of the 1xx replies.
For the stateful mode, I do agree that the handling of 100 is a bit special.
Regards,
Bogdan
Paul Kyzivat wrote:
> The point is that 100 is very special. When 1xx is used
AFAIK, 100 is a 1xx response but it differs from other 1xx responses because:
1. it doesn't establish a dialog
2. it cannot (and must not) be sent realiably
Regards,
Attila
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iñaki Baz
Castillo
Sent: 20 Aug
The point is that 100 is very special. When 1xx is used it means
101-199. 100 is special because it is hop-by-hop, while all the others
are e2e.
Thanks,
Paul
Bogdan-Andrei Iancu wrote:
> Hi Iñaki,
>
> Perfectly right!
> single correction -? 1xx response start from 100 and not f
Both mean the same.
RFC 3261 - Section 7.2
any response with a status code between 100 and 199 is
referred to as a "1xx response"
1xx: Provisional -- request received, continuing to process the
request;
Potato potato theory.
- Ben.
- Original Message
F
El Wednesday 20 August 2008 18:09:37 Bogdan-Andrei Iancu escribió:
> Hi Iñaki,
>
> Perfectly right!
> single correction -? 1xx response start from 100 and not from 101 - 100
> Trying is a 1xx response
Thanks, I was doubting since, I don't remember where, I read that 100 is not
an 1xx response...
Hi Iñaki,
Perfectly right!
single correction -? 1xx response start from 100 and not from 101 - 100
Trying is a 1xx response
Regards,
Bogdan
Iñaki Baz Castillo wrote:
> Hi, just to clarify:
>
> - "provisional response" is any response between 100 and 199.
>
> - "1xx response" is any response be
El Wednesday 20 August 2008 17:45:10 Iñaki Baz Castillo escribió:
> > If UA communicates thru a stateful Proxy to another UA?
>
> The same.
To clarify: the stateful proxy (if just "transaction stateful") will have no
issues if there are not "From tag". But the UAC and UAS will have.
--
Iñaki Ba
Please refer Section - 8.1.1.3 From of RFC 3261. It also points to section 19.3
for details of tag.
- Digambar Rasal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George AK
Sent: 20 August 2008 09:52
To: sip-implementors@lists.cs.columbia.edu; [EMAIL
Hi, just to clarify:
- "provisional response" is any response between 100 and 199.
- "1xx response" is any response between 101 and 199.
Am I right?
--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>
___
Sip-implementors mailing list
Sip-implementors@lists.c
El Wednesday 20 August 2008 10:51:53 George AK escribió:
> One old question.
> Why the From-Tag is required?
> If UA communicates directlty to another UA?
It's required to asociate transactions with their corresponding dialogs (the
same UA could establish various dialogs/sessions with other UA,
> Why the From-Tag is required?
Per rfc3261, the answer is that the tags and call-id identify the
dialog.
The other answer is that prior to such a requirement, requests in the
opposite direction over the dialog occasionally caused To tag to be
added because the receive was unaware that the dialog
One old question.
Why the From-Tag is required?
If UA communicates directlty to another UA?
If UA communicates thru a stateful Proxy to another UA?
Is B2BUA the only guy who will cry if there is no From-Tag?
If we allow the Callee to put his To-tag in the To header itself when he
sending reINVITE,
El Wednesday 20 August 2008 17:08:08 Paul Kyzivat escribió:
> The scoping of Allow is not at all well defined.
> So it might be that you *did* support UPDATE when you sent an Allow
> mentioning it, but stopped supporting it later. But its silly to provoke
> this problem by claiming you allow someth
Iñaki Baz Castillo wrote:
> El Wednesday 20 August 2008 16:29:22 Jagan Mohan escribió:
>> Hi All,
>>
>>I would like to know whether a B2BUA can insert the SIP Methods it
>> support in the Allow header, when a SIP call is made between two UAs
>> through the B2BUA.
>>
>>If yes, then I have
Jagan Mohan wrote:
> Hi All,
>
>I would like to know whether a B2BUA can insert the SIP Methods it
> support in the Allow header, when a SIP call is made between two UAs through
> the B2BUA.
There are *no* rules for B2BUAs, other than that each *side* must behave
correctly as a UA. There a
Hi Jagan
Yes, B2bua can insert the sip methods in the ALLOW header.
For the response for the unsupported codec, I think the B2bua will respond
back with 488, as per the extract from RFC 3311 below
*If the new session description is*
* not acceptable, the UAS can reject it by returning a 488 (Not
El Wednesday 20 August 2008 16:36:20 Iñaki Baz Castillo escribió:
> > Should it be send as %23? Does any RFC mention so?
I forgot to say that this is defined in the BNF section of RFC 3261.
--
Iñaki Baz Castillo
[EMAIL PROTECTED]
___
Sip-implementors
El Wednesday 20 August 2008 16:29:22 Jagan Mohan escribió:
> Hi All,
>
>I would like to know whether a B2BUA can insert the SIP Methods it
> support in the Allow header, when a SIP call is made between two UAs
> through the B2BUA.
>
>If yes, then I have query on the following call flow:
>
>
El Wednesday 20 August 2008 16:24:50 Koshy Thomas escribió:
> Hi,
>I have query regarding sending of symbol # in a SIP INVITE message
> Request-Line.
> Should it be send as %23? Does any RFC mention so?
The SIP ABNF doesn't allow '#' as method name (INVITE, BYE...), as protocol
("sip", "sips"
Hi All,
I would like to know whether a B2BUA can insert the SIP Methods it
support in the Allow header, when a SIP call is made between two UAs through
the B2BUA.
If yes, then I have query on the following call flow:
UAC B2BUA UAS.
Say, UAC and B2BUA support UPDATE metho
On Wed, 2008-08-20 at 19:29 +0530, Vivek Batra wrote:
> Thanks to all for your suggestions!
>
> Few ITSP disconnects the call when INVITE is challenged by called party viz
> (B). E.g., VoIPtalk
>
> When (B) sends 407 Auth. to VoIPtalk server, VoIPtalk then sends 486 Busy to
> caller viz (A). Hen
Hi,
I have query regarding sending of symbol # in a SIP INVITE message
Request-Line.
Should it be send as %23? Does any RFC mention so?
Thanks
Koshy
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu
Thanks to all for your suggestions!
Few ITSP disconnects the call when INVITE is challenged by called party viz
(B). E.g., VoIPtalk
When (B) sends 407 Auth. to VoIPtalk server, VoIPtalk then sends 486 Busy to
caller viz (A). Hence, call does not get through using VoIPtalk.
Is it right implementa
one more thing, you can add any proprietary via parameter provided
the following conditions are met:
1. it doesn't conflict with any already-existing via parameter
and
2. it complies with the via-extension grammar in RFC 3261
Regards,
Attila
-Original Message-
From: [EMAIL PROTECTED]
[
As far as I know, parameters that have an "x-" prefix are usually
proprietary.
As a proxy, any Via parameter not understood, should be forwarded
without any fuss.
As a user-agent, any Via parameter not understood should be copied and
used in the response.
Via headers often can have proprietary p
40 matches
Mail list logo
