and B2BUA initiates a call leg to Carol for Bob..
and the proxy will know that this happened because he "Record Routes".
Ok it's true for some other services a B2BUA is mandatory or they haven't found yet a solution using proxies and methods.. but for issues like "we are not sure if the BYE reached its destination etc" I think this should not be the problem for SIP and for that reason change the all philosophy behind it..Improve the NETWORK should be the solution!
I don't know.. it's sad don't you think? Anyway thanks for the replies!
???: sip-implementors-request at lists.cs.columbia.edu <sip-implementors-request at lists.cs.columbia.edu>
????: Sip-implementors Digest, Vol 71, Issue 41
????: sip-implementors at lists.cs.columbia.edu
??????????: ?????, 24 ??????????? 2009, 0:18
Send Sip-implementors mailing list submissions to
sip-implementors at lists.cs.columbia.edu
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
or, via email, send a message with subject or body
'help' to
sip-implementors-request at lists.cs.columbia.edu
You can reach the person managing the list at
sip-implementors-owner at lists.cs.columbia.edu
When replying, please edit your Subject line so it is more
specific
than "Re: Contents of Sip-implementors digest..."
1. Re: About hexadecimal un-escaping (Dale Worley)
2. Re: About hexadecimal un-escaping (I?aki Baz
Castillo)
3. Re: in-active in answer with sendonly in offer
(Andrea Rizzi)
4. Re: CSeq header field in Register request (Dale
Worley)
5. Re: B2BUA vs Proxy with Record Route (Dale Worley)
6. Re: CSeq header field in Register request (cool
goose)
7. Diagnostic idea (Dale Worley)
8. Re: CSeq header field in Register request (Dale
Worley)
9. Re: Diagnostic idea (Brett Tate)
10. Re: CSeq header field in Register request (cool
goose)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Feb 2009 14:20:55 -0500
From: "Dale Worley" <dworley at nortel.com>
Subject: Re: [Sip-implementors] About hexadecimal
un-escaping
To: I?aki Baz Castillo <ibc at aliax.net>
Cc: sip-implementors at lists.cs.columbia.edu
<1235416856.6505.26.camel at victoria-pingtel-com.us.nortel.com>
Content-Type: text/plain; charset=utf-8
On Sat, 2009-02-21 at 03:43 +0100, I?aki Baz Castillo
There is no "escaping in SIP" -- there
are five or seven syntactic
locations in SIP URIs/name-addrs, and each has
its own escaping rules.
Which of those contexts are you considering?
For example, URI or header paramenters keys and value
allow hexadecimal
escaping. SIP URI username also allows hexadecimal
escaping.
user name: "unreserved" and
"user-unreserved" are allowed, uses
%-escaping
URI parameter name: "unreserved" and
"param-unreserved" are allowed,
uses %-escaping
URI parameter value: same as URI parameter name
header parameter (or "header" in the BNF, *not*
"unreserved" and "hnv-unreserved" are
allowed, uses %-escaping
As far as I know, the "+ represents space" escape
is not used in SIP
URIs in any way, only in HTTP URLs.
Dale
------------------------------
Message: 2
Date: Mon, 23 Feb 2009 20:34:16 +0100
From: I?aki Baz Castillo <ibc at aliax.net>
Subject: Re: [Sip-implementors] About hexadecimal
un-escaping
To: sip-implementors at lists.cs.columbia.edu
Message-ID: <200902232034.16111.ibc at aliax.net>
Content-Type: text/plain; charset="utf-8"
On Sat, 2009-02-21 at 03:43 +0100, I?aki Baz Castillo
There is no "escaping in SIP" --
there are five or seven syntactic
locations in SIP URIs/name-addrs, and each
has its own escaping rules.
Which of those contexts are you considering?
For example, URI or header paramenters keys and
value allow hexadecimal
escaping. SIP URI username also allows
hexadecimal escaping.
user name: "unreserved" and
"user-unreserved" are allowed, uses
%-escaping
URI parameter name: "unreserved" and
"param-unreserved" are allowed,
uses %-escaping
URI parameter value: same as URI parameter name
header parameter (or "header" in the BNF,
"unreserved" and "hnv-unreserved"
are allowed, uses %-escaping
As far as I know, the "+ represents space"
escape is not used in SIP
URIs in any way, only in HTTP URLs.
Really thanks.
--
I?aki Baz Castillo
------------------------------
Message: 3
Date: Mon, 23 Feb 2009 21:18:12 +0100
From: "Andrea Rizzi"
<andrea.rizzi at yahoo.it>
Subject: Re: [Sip-implementors] in-active in answer with
sendonly in
offer
To: <sip-implementors at lists.cs.columbia.edu>
<248572C31DBA4CA290259B5D23A5226B at fastwebit.ofc>
Content-Type: text/plain; charset="us-ascii"
Answering with inactive may also be used to save bandwidth
(in addition to
DSP resources as already mentioned) in the call hold
scenario. Inactive will
force the holding party to stop sending media, leaving the
held party to
generate proper notification to the user (a message, a
special hold tone o
whatever else). In my opinion, the hold service model in
RFC 3264 is
targeted to the MOH one, while it is actually not always
really needed.
Saving bandwidth is still relevant on the access side, and
if you allow the
hold service to the user, you need to reserve a 50% more
bandwidth/line just
to play, for instance, a hold tone. Of course this would
require the CPE
(and the PSTN gateway) to play "locally" the
tone/notification, this would
be up to the operator policy (and supported by CPE/gw
vendors)
Andrea
----------------------------------------------------------------------
Message: 1
Date: Fri, 20 Feb 2009 11:42:49 -0800 (PST)
From: kaiduan xie <kaiduanx at yahoo.ca>
Subject: [Sip-implementors] in-active in answer with
sendonly in offer
To: sip-implementors at lists.cs.columbia.edu
<185354.24392.qm at web65709.mail.ac4.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1
Hi, all,
What is the purpose of putting inactive in answer when
receiving a sendonly
offer? 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."
In rfc5359, recvonly is returned in hold case.
Thanks,
kaiduan
__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and
bookmark your
favourite sites. Download it now at
http://ca.toolbar.yahoo.com.
------------------------------
Message: 4
Date: Mon, 23 Feb 2009 16:03:04 -0500
From: "Dale Worley" <dworley at nortel.com>
Subject: Re: [Sip-implementors] CSeq header field in
Register request
To: cool goose <coolgoose8182 at gmail.com>
Cc: sip-implementors at lists.cs.columbia.edu
<1235422984.6505.44.camel at victoria-pingtel-com.us.nortel.com>
Content-Type: text/plain
Can someone explain me the importance of CSeq in
REGISTER request? RFC 3261
specifies that UA must increment the CSeq value by one
for each REGISTER
request with the same Call-ID. What is the expected
response from a
registrar if a UA keeps retransmitting the REGISTER
request with same CSeq
value and the same Call-ID?
The registrar will keep a record for several minutes of the
REGISTER
that it received and the response that it gave to the
REGISTER. When it
receives a duplicate of the REGISTER, it will send a
duplicate of the
response, without further processing. (This is necessary
because the
Internet can duplicate UDP messages, and also to all the
sender to
re-send if the response gets lost.)
After the registrar has purged memory of the REGISTER (with
that CSeq),
it will most likely respond to further REGISTERs with that
CSeq will a
500 "Out of order" response.
Dale
------------------------------
Message: 5
Date: Mon, 23 Feb 2009 16:07:08 -0500
From: "Dale Worley" <dworley at nortel.com>
Subject: Re: [Sip-implementors] B2BUA vs Proxy with Record
Route
To: Vito Korleone <extusiano at yahoo.gr>
Cc: sip-implementors at lists.cs.columbia.edu
<1235423228.6505.47.camel at victoria-pingtel-com.us.nortel.com>
Content-Type: text/plain
Why "we" need a B2BUA?? Can't we just
have the same functionality if
we replace him with a proxy and insert the Record
Route field to trace
all messages between the subscribers??
You are correct, for almost all purposes, a proxy works
very well. And
it generally has lower overhead than a B2BUA.
For example, the sipX open-source PBX uses a proxy as the
core of its
architecture.
Dale
------------------------------
Message: 6
Date: Mon, 23 Feb 2009 13:25:14 -0800
From: cool goose <coolgoose8182 at gmail.com>
Subject: Re: [Sip-implementors] CSeq header field in
Register request
To: Dale Worley <dworley at nortel.com>
Cc: sip-implementors at lists.cs.columbia.edu
<7ca669540902231325s7d30c871u6773804050d9d289 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thank You very much for the response guys!
What about the Call-ID? If the same UA sends the REGISTER
requests with
different cal-IDs, what would be the ideal response from
the registrar? I
know that RFC 3261 prohibits from doing this. If UA fails
to use the same
Call-ID, how will it effect the registrar in ordering the
requests?
CoolGoose.
On Mon, Feb 23, 2009 at 1:03 PM, Dale Worley
Can someone explain me the importance of CSeq in
REGISTER request? RFC
3261
specifies that UA must increment the CSeq value
by one for each REGISTER
request with the same Call-ID. What is the
expected response from a
registrar if a UA keeps retransmitting the
REGISTER request with same
CSeq
value and the same Call-ID?
The registrar will keep a record for several minutes
of the REGISTER
that it received and the response that it gave to the
REGISTER. When it
receives a duplicate of the REGISTER, it will send a
duplicate of the
response, without further processing. (This is
necessary because the
Internet can duplicate UDP messages, and also to all
the sender to
re-send if the response gets lost.)
After the registrar has purged memory of the REGISTER
(with that CSeq),
it will most likely respond to further REGISTERs with
that CSeq will a
500 "Out of order" response.
Dale
------------------------------
Message: 7
Date: Mon, 23 Feb 2009 16:37:27 -0500
From: "Dale Worley" <dworley at nortel.com>
Subject: [Sip-implementors] Diagnostic idea
To: sip-implementors
<sip-implementors at lists.cs.columbia.edu>
<1235425047.6505.64.camel at victoria-pingtel-com.us.nortel.com>
Content-Type: text/plain
I've been considering the following idea for a
diagnostic tool, and I'd
like to get some feedback on it.
The goal is to be able to trace the progress of a SIP
request through
the network, including seeing the forking structure. We
first need to
pick a provisional response codes. It appears that
"170" is not
currently used. This response code is also used as an
option-tag for
this feature. The processing is that whenever a SIP
element receives a
request that contains "Supported: 170", the
element will immediately (in
addition to anything else that it would do with the
request) send a 170
response upstream, containing the request as its body
(media type
message/sipfrag).
Dale
------------------------------
Message: 8
Date: Mon, 23 Feb 2009 16:41:05 -0500
From: "Dale Worley" <dworley at nortel.com>
Subject: Re: [Sip-implementors] CSeq header field in
Register request
To: cool goose <coolgoose8182 at gmail.com>
Cc: sip-implementors at lists.cs.columbia.edu
<1235425265.6505.70.camel at victoria-pingtel-com.us.nortel.com>
Content-Type: text/plain
What about the Call-ID? If the same UA sends the
REGISTER requests
with different cal-IDs, what would be the ideal
response from the
registrar? I know that RFC 3261 prohibits from doing
this. If UA fails
to use the same Call-ID, how will it effect the
registrar in ordering
the requests?
See RFC 3261 section 10.3. The rules are messy, but they
give the
results one would want to get.
Dale
------------------------------
Message: 9
Date: Mon, 23 Feb 2009 13:52:59 -0800
From: Brett Tate <brett at broadsoft.com>
Subject: Re: [Sip-implementors] Diagnostic idea
To: Dale Worley <dworley at nortel.com>,
sip-implementors
<sip-implementors at lists.cs.columbia.edu>
<9B2A061A1137254BBE4F4B2CD843646A10B1FA9ADC at mbx02.citservers.local>
Content-Type: text/plain; charset="us-ascii"
Sounds somewhat similar to
draft-ietf-sip-hop-limit-diagnostics. The 170 proposal
would potentially suffer from similar message size,
security, and privacy issues.
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-
implementors-bounces at lists.cs.columbia.edu] On Behalf
Of Dale Worley
Sent: Monday, February 23, 2009 4:37 PM
To: sip-implementors
Subject: [Sip-implementors] Diagnostic idea
I've been considering the following idea for a
diagnostic tool, and I'd
like to get some feedback on it.
The goal is to be able to trace the progress of a SIP
request through
the network, including seeing the forking structure.
We first need to
pick a provisional response codes. It appears that
"170" is not
currently used. This response code is also used as an
option-tag for
this feature. The processing is that whenever a SIP
element receives a
request that contains "Supported: 170", the
element will immediately (in
addition to anything else that it would do with the
request) send a 170
response upstream, containing the request as its body
(media type
message/sipfrag).
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
------------------------------
Message: 10
Date: Mon, 23 Feb 2009 14:18:24 -0800
From: cool goose <coolgoose8182 at gmail.com>
Subject: Re: [Sip-implementors] CSeq header field in
Register request
To: Dale Worley <dworley at nortel.com>
Cc: sip-implementors at lists.cs.columbia.edu
<7ca669540902231418t734efe3an5828e989c92188dc at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
"If the Call-ID value in the existing binding differs
from the
Call-ID value in the request, the binding MUST be
removed if
the expiration time is zero and updated
otherwise."
Does this mean that the Register requests from same UA can
have different
Call-IDs as long as the CSeq values are not the same?
On Mon, Feb 23, 2009 at 1:41 PM, Dale Worley
What about the Call-ID? If the same UA sends the
REGISTER requests
with different cal-IDs, what would be the ideal
response from the
registrar? I know that RFC 3261 prohibits from
doing this. If UA fails
to use the same Call-ID, how will it effect the
registrar in ordering
the requests?
See RFC 3261 section 10.3. The rules are messy, but
they give the
results one would want to get.
Dale
------------------------------
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
End of Sip-implementors Digest, Vol 71, Issue 41
************************************************