rfc5589
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Vivek Talwar
Sent: Tuesday, February 22, 2011 9:44 PM
To: Nahum Nir; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors]
Sun,
I don't think answerer has the obligation to responds the offerer with the same
answer as previous one.
In session refresh, this sort of scenario occurs frequently.
The answerer might take the chance to do call hold, MoH etc.
Similar talk at
https://lists.cs.columbia.edu/pipermail/sip-imp
What comes to my mind is UA sometimes has preference in conveying DTMF
in signaling path (INFO, NOTIFY) or telephone-event in media path.
So suppose A and B is in talk,
If A does not prefer convey DTMF in telephone-event, it send offer as
follows,
m=audio 49170 RTP/AVP 0 4
a=rtpmap:0 PCMU/
2009 5:24 AM
To: Dale Worley
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Can EP send media only peer supports
comment at end.
Dale Worley wrote:
> On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote:
>> I think answerer can add additional codec
Paul,
If I catch you clearly, do you mean this is a real bug in RFC3264?
Do we have some formal doc/draft to clarify usage here?
Thanks
Regards,
-Rockson
-Original Message-
From: Paul Kyzivat (pkyzivat)
Sent: Saturday, August 15, 2009 7:54 AM
To: Dale Worley
Cc: Rockson Li (zhengyli
Hi folks,
Going through RFC3264, I find some inconsistency between offerer and
answerer.
Suppose offer/answer below
Offer:
m=audio 49170 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
Answer:
m=audio 49172 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
I th
Cool,
The +sip.instance is actually defined in draft-ietf-sip-outbound based
on RFC3840
9. Contact Header Field
This specification extends the Contact header field. In particular,
it allows for the Contact header field parameters to include
feature-param. Feature-param is a feature p
I don't think so
Sec 5.1 of RFC3264
Note
that in the case of the Real Time Transport Protocol (RTP) [4], RTCP
is still sent and received for sendonly, recvonly, and inactive
streams. That is, the directionality of the media stream has no
impact on the RTCP usage.
Regards,
-Rocks
Yes.
RFC5057
5.4. Target Refresh Requests
Target refresh requests update the remote target of a dialog when
they are successfully processed. The currently defined target
refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER
[7]).
Regards,
-Rockson
李征宇
-Original Mess
I do NOT think you need handle expires header in provisional resp,
The meaning of expires header is not well-defined.
And RFC3261 does not say you need update C timer based on expires
header.
In sec 20.19, it just say
The expiration time in an INVITE does not affect the duration of the
actual s
There're bugs in loop detection of rfc3261,
Check draft-ietf-sip-fork-loop-fix-08, which will fix it eventually.
Regards,
-Rockson
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Bogdan-Andrei Ian
Sdp should not be present in the 200(INVITE),
RFC3261 sec 13.2.1 Creating the Initial INVITE
o Once the UAS has sent or received an answer to the initial
offer, it MUST NOT generate subsequent offers in any responses
to the initial INVITE. This means that a UAS based on
Harbhanu,
I agree with you, addr-spec must be used as well for Refer-To.
However, looks like RFC3515 does not state this explicitly.
Regards,
-Rockson
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf
In most of th cases, it would be fine.
However, I think branch value is strongly recommended.
Suppose a stateful proxy, which doing parallel forking by push a new top
route header to retrain the original Req-URI.
A -F1->proxy F2>INVITE original Req-uri
I agree with Maxim here.
If dialog terminates before transaction, RFC3261 does not say clearly
if UA need destroy those transactions explicitly or let them complete
their lifecycle.
I think it's up to implementation.
Regards,
-Rockson
-Original Message-
From: sip-implementors-boun...@list
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
The PRACK w/ offer is optional in your case
Regards,
-Rockson
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
pravin.sw...@wipro.com
Sent: Friday, December 19, 2008 10:35 PM
To: sip-implementors@
comments inline :-)
-Rockson
From: Arunachala [mailto:arun1...@gmail.com]
Sent: Wednesday, December 17, 2008 4:49 PM
To: Rockson Li (zhengyli)
Cc: tamal.bis...@wipro.com; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] INVITE Behaviour
Also here list all content-encoding registry
http://www.iana.org/assignments/http-parameters
-Rockson
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of I?aki Baz
Castillo
Sent: Wednesday, December
IMO, you should differentiate the retransmission of PRACK in uac core
and transaction layer.
PRACK is a normal req, which has its own transaction, so it's
transaction who would assure the retransmission of the PRACK, not UAC
core layer.
On retransmission in transaction expires, I don't think it's
I think 415 is too specific, there's no limitation in RFC3261 that 400
is only applicable to msg headers.
Regards,
-Rockson
-Original Message-
From: Avasarala Ranjit-A20990 [mailto:[EMAIL PROTECTED]
Sent: Monday, December 08, 2008 3:03 PM
To: Rockson Li (zhengyli); Tarun2 Gupta;
I agree with Tarun here
Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Tarun2 Gupta
Sent: Monday, December 08, 2008 11:39 AM
To: Maxim Sobolev; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Proper negative final status c
Hi Paul and all,
I was thinking if we could draw some state diagram to show what's
desired state, offer state and current state's interaction on the sdp
offer/answer stream direction.
This is my initial rough diagram
Scenario 1)
Suppose UA get a SDP offer,
SDP offer>
, November 29, 2008 4:25 AM
To: Rockson Li (zhengyli)
Cc: sip-implementors@lists.cs.columbia.edu; [EMAIL PROTECTED]
Subject: Re: [AVT] how to identify a RTP session
The basic idea is that if the participants share a single SSRC space,
they form a single RTP session.
Colin
On 28 Nov 2008, at 03
13.2.1 Creating the Initial INVITE
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. T
Iñaki Baz Castillo:
> El Viernes, 28 de Noviembre de 2008, Rockson Li (zhengyli) escribió:
>> why there're only three RTP sessions, I think it should be six?
>> since "each participant receiving from the other two on separate port
>> pairs"
>> which means
Hi folks,
Recently, I am confused on the identity of a RTP session.
per RFC3550
RTP session: An association among a set of participants
communicating with RTP. ... A participant distinguishes
multiple RTP sessions by reception of different sessions using
different pairs
When I first encounter the issue is interworking with openser server,
which adds lr=on, but I don't know who is the original author of this behavior.
Regards,
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Thursday, N
Paul,
I wonder why you think the first subscribe fails with a 500 due to out
of order CSeq number.
Sine the second one would be sent with Cseq+1 as in first one.
I don't see out of order CSeq number issue here.
Thanks
Regards,
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:
avior, which definitely applies to registrar.
fyi
-Rockson
-Original Message-
From: Raj Jain [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2008 7:40 AM
To: Neelakantan Balasubramanian
Cc: Bob Penfield; Rockson Li (zhengyli); Tarun2 Gupta;
sip-implementors@lists.cs.columbia.edu
Subjec
IMO, to tag is meaningless for REGISTER request, it's not necessary to
add to tag in REGISTER when you need to refresh the registration.
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Tarun2 Gupta
Sent: Friday, November 21, 2008 1:07 PM
To: sip
Rohit,
The ini-INVITE only has 100rel in Supported header, so I don't think
it's a issue as this regards.
Yes,there's no SDP in 180.
Regards,
-Rockson
-Original Message-
From: Rohit Aggarwal [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 11:51 AM
To: Rocks
Hi folks,
Can UAS send interleaving reliable/unreliable response, like first a
reliable 183,
then a unreliable 180?
A B
|-|
|INVITE-->|
|<---100Trying|
|<-
Comments inline.
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bhandari, Ankit (Ankit)
Sent: Saturday, November 08, 2008 1:33 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Timer for Provisional response if UAC gets
1
Yes, I think so. NOTIFY would be a mid-dialog request as constructed
with Route header as normal mid-request specified in RFC3261.
-Rockson
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, November 06, 2008 8:44 PM
No, 200OK retransmission is stopped until ACK's arrival or 64*T1. PRACK has no
impact on this.
Check RFC3261 sec 13.3.1.4
fyi
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Siddhardha Garige
Sent: Thursday, November 06, 2008 3:16 PM
To: sip-im
Sdp w/o m line is the recommended usage in 3pcc,
See RFC3725 sec4.4, if you would like better interop, you'd better not
reject this.
If you do need reject, I think 606 Not Acceptable might be better for
case1, and your handling for case2 is fine to me.
-Rockson
-Original Message-
From:
Romel,
I think the reason RFC3262 only uses reliable response as examples is
UPDATE is ONLY used as mid-dialog(either early or confirmed) request,
Though unreliable response can establish dialog, but you cannot assume
Unreliable response arrives since it's unreliable.
-Rockson
-Original Me
Subbu,
RFC3264 has stated 0.0.0.0 is not only used in call hold.
And you should not send any RTP/RTCP data to stream of 0.0.0.0
RFC3264 sec 8.4
An agent MUST be capable of receiving SDP with a
connection address of 0.0.0.0, in which case it means that neither
RTP nor RTCP should be sent t
Brett,
See comments inline.
Thanks
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Brett Tate
Sent: Thursday, October 16, 2008 10:08 PM
To: Rohit Aggarwal; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Significance of
Shane,
I think not to end the call might be fine.
But to act as if "refresher=uac" is received might be troublesome,
Since UAC does not know if UAS decides to refresh itself,
in that case, you would end up with glare re-INVITE when both sides
intend to refresh later.
I think it would be better t
I think it's legal for UAC to BYE the dialog,
As per RFC4028
9. UAS Behavior
The UAS MUST set the value of the refresher parameter in the
Session-Expires header field in the 2xx response.
Without refresher parameter, UAC might think it's a bad request.
So just end the call.
-Rockson
--
cular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer.
FYI
-Rockson
-Original Message-
From: Greg Dykes [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2008 10:28 AM
To: Rockson Li (zh
Greg,
Payload Type negotiated will be used as RTP PT in RTP packet.
And if you use named events in RFC2833, the events supported are
negotiated.
Regards,
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Greg Dykes
Sent: Saturday, September 27, 20
Navneet,
You need to ignore any Contact header in non target-refresh
request/response.
RFC5057 sec5.4
Target refresh requests update the remote target of a dialog when
they are successfully processed. The currently defined target
refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY
f only has one Via.
FYI
-Rockson
From: Sourav Dhar Chaudhuri [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 18, 2008 3:44 PM
To: Rockson Li (zhengyli)
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Can multiple Via header be
I think the answer is "no".
RFC3261 mandates UAC only insert a Via header when sending request.
Sec 8
When the UAC creates a request, it MUST insert a Via into that request.
And respnse with multiple Via would be rejected by UAC.
Sec 8.1.3.3
If more than one Via header field value is prese
Paul,
Some questions inline.
Many thanks
Regards,
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat
(pkyzivat)
Sent: Thursday, September 18, 2008 6:23 AM
To: Iñaki Baz Castillo
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re:
Yes, Notify alone is enough to establish dialog in UAC.
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
dushyant
Sent: Wednesday, September 17, 2008 3:53 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Query related to
receives aCANCELafter
forwarding a 200 OK ?
2008/9/17, Rockson Li (zhengyli) <[EMAIL PROTECTED]>:
> Hi, imagine A calls B via proxy P:
>
> - A sends the INVITE to P.
> - P forwards to B.
> - B replies a 200 OK that arrives to P (this would cause proxy core to
> terminat
Inaki,
one question below.
Regards,
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Wednesday, September 17, 2008 4:28 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] What should do a proxy if
comments inline
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
krishna kalluri
Sent: Monday, September 15, 2008 11:01 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] question regarding REGISTER - RFC 3665
Hi,
I have a
Jaqan,
Additional codec might be added in sdp answer besides those in sdp
offer.
See RFC3264 sec 6.1
The stream MAY indicate additional media formats, not listed in the
corresponding stream in the offer, that the answerer is willing to
send or receive
-Rockson
-Original Message-
Paul,
Not sure if you read draft-rosenberg-sip-ua-loose-route or not.
I think it talks about the preservation of orig-RURI for service
identification.
FYI
Regards,
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Kyzivat (pkyzivat)
Sent: T
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Monday, September 08, 2008 5:20 PM
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Question on proxy routing
2008/9/8, Rockson Li (zhengyli) <[EM
ptember 08, 2008 4:29 PM
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Question on proxy routing
2008/9/8, Rockson Li (zhengyli) <[EMAIL PROTECTED]>:
> Franz,
>
> IMO, the proxy need first replace the req-uri with target, and
> forward the request
Franz,
IMO, the proxy need first replace the req-uri with target, and forward
the request to next hop based top route.
The reason is as per RFC3261
1)Proxy first Determining Request Targets based on req-uri
2)then forward the req
2.1) update the req-uri with target(16.6 Request Forwarding item 2
Moveover, even RTP is sent after ACK, it might/probably arrive after RTP, since
proxy in the middle might add Record-Route itself,
So ACK need to traverses through proxy whereas RTP does not.
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?ak
Actually, SIP tires to be simple here,
The 200 bytes gap here is assumed that the response can be hold.
You can check historic email on this initial intention:
http://www.ietf.org/mail-archive/web/sip/current/msg02184.html
And a draft was written for this issue later:
draft-gurbani-sip-large-udp
IMO, if the desired precondition direction tag is set to "none",
It simply means no resource is needed in the peer from local point of
view.
So I think peer can just ignore it.
And in RFC3312 sec5.1.1, I do not see any possibility that offer would
be with direction type "none".
-Rockson
-
I do NOT think this is a conflict here.
Pname defined in RFC3261 is used as SIP-URI or SIPS-URI parameter.
Whereas pname defined in RFC3966 is a parameter for tel URI.
The context in which pname used is different, though the same "pname" is used,
they
Are essentially different entities.
-Rockso
Agree with Inaki here.
More info here
11.2 Processing of OPTIONS Request
This use of OPTIONS has limitations due to the differences in proxy
handling of OPTIONS and INVITE requests. While a forked INVITE can
result in multiple 200 (OK) responses being returned, a forked
OPTIONS will
So another bug here?
The *MUST* in "10. Generate CANCELs" cannot apply to non-INVITE client
transactions
-Rockson
-Original Message-
From: Attila Sipos [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 3:50 PM
To: Rockson Li (zhengyli); sip-implementors@lists.cs.co
Hi folks,
Suppose a proxy which forks OPTIONS to two endpoints,
endpoint A responds with 200 promptly, endpoint B responds with 100.
so does proxy need to send to CANCEL to endpoint B?
from RFC3261,
16.7 Response Processing
10. Generate CANCELs
If the forwarded response wa
Thanks, I should really reread that part.
-Original Message-
From: Michael Procter [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 3:09 PM
To: Rockson Li (zhengyli); sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] which parameter is not allowed in
Req
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
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
te pain on this issue.
Thanks a lot
Regards,
-Rockson
-Original Message-
From: Robert Sparks [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 11:36 PM
To: Rockson Li (zhengyli)
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Can proxy forward a req
Hi folks,
RFC3261
sec 16.6 Request Forwarding
6. Postprocess routing information
If the proxy has a local policy that mandates that the request
visit one specific proxy, an alternative to pushing a Route
value into the Route header field is to bypass the forwarding
It's definitely ok for UAS to send mid-early-dialog to UAC.
One scenario, I can think of is UPDATE to update early dialog session.
Check RFC3311 sec 5.1
FYI
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Saturday, Aug
>Sections 12.1.1 says:
>
> When a UAS responds to a request with a response that establishes a
> dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
> header field values from the request into the response (including the
> URIs, URI par
Rockson Li (zhengyli) escribió:
> > 2) - UAS receives a CANCEL for an INVITE transaction for which UAS
> > has already sent a final response. In this case RFC3261 says:
> >
> >"the CANCEL
> >request has no effect on the processing of the original requ
Comments inline.
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Thursday, August 14, 2008 7:12 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] About CANCEL proccesing in a UAS
Hi, "9.2 Server
I think you're mostly correct.
Request(CANCEL is not special) retransmission is first checked in server
transaction layer based on server transaction match( RFC3261 sec 17.2.3.)
ACK for a non 2XX final response is special, since there's no client/server
transaction for ACK for non-2xx, it is han
Hi ,
I think the outbound draft means, you need two edge proxies, one for
calling party, the other one for called party.
And the two EPs would insert Record-Route with UA's specific flow token,
But it would only work for incoming request, ie, route the req to UA.
EP just remove Route(which points
George,
In rfc 3261 16.7 . (5. Check response for forwarding ...)
It says you first
Until a final response has been sent on the server transaction,
the following responses MUST be forwarded immediately:
- Any provisional response other than 100 (Trying)
Bharat,
You are mostly correct.
One point I want to add is you might get SDP answer in reliable response
instead of 200, though this is seldom used in real world, but It's totally
correct as per spec.
You can also check out RFC3264 sec 8.3.1 Modifying Address, Port or Transport
FYI
-Rockson
t: Tuesday, August 05, 2008 9:40 PM
To: Rockson Li (zhengyli)
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] question on RFC5057 Multiple Dialog
Usages in SIP
Even if the NOTIFY is sent after the 2xx (SUBSCRIBE) it may arrive
first. And in the case if forking it may arri
Hi guys,
On RFC5057 sec 6.
Carol accepts Alice's invitation to replace her dialog (invite usage)
with Bob
...
Bob then ends his invite usages with both Alice and Carol using BYEs.
however, I don't see Carol send BYE to terminate the dialog(invite
usage) with Bob in Figure 5.
And if Carol s
Hi folks,
I think the first NOTIFY message should be sent after 2xx(SUBSCRIBE).
This is described in RFC3265 sec3.1.6.2
Note that a NOTIFY message is always sent immediately after any 200-
class response to a SUBSCRIBE request, regardless of whether the
subscription has already been
Yes, you can only drop ACK silently without any response.
Actually, there's bug here, RFC3261 does not say response to ACK is not
needed, people just accept it.
Check this out :
http://www.ietf.org/mail-archive/web/sip/current/msg07238.html
-Rockson
-Original Message-
From: [EMAIL PROT
inline
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ivar Lumi
Sent: Wednesday, July 30, 2008 11:31 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] UAS early dialog to confirmed
Hi,
When UAS early dialog get into con
I think comma is allowed in display name, it falls into %x23-5B of qdtext.
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, July 30, 2008 12:53 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-impleme
incremented
byone for each SDP answer?
From: "Rockson Li (zhengyli)" <[EMAIL PROTECTED]>
I also got a question here, when UA sends an offer, RFC3264 says it
must
increment the o line version by one.
However, it does not say when we send an answer, we need increment
the o
--Original Message-----
From: Rockson Li (zhengyli)
Sent: Thursday, July 24, 2008 6:24 PM
To: '[EMAIL PROTECTED]'; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] O= line mismatch in the ACK for the
force SDPoffer
This is a interesting question,
Actually, RFC3264
This is a interesting question,
Actually, RFC3264 does not explicitly say this answer would be rejected.
My guess is just ignore it and resume it as a valid answer.
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursda
Mahesh,
I guess Paul might talk about RFC4317 SDP Offer/Answer Examples
FYI
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Kyzivat (pkyzivat)
Sent: Tuesday, July 15, 2008 11:33 PM
To: Mahesh Kumar
Cc: sip-implementors@lists.cs.columbia.e
I agree with Theo here,
Actually RFC3261 here is quite obscure, IMO.
12.1.1 UAS behavior
When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), ...
The UAS MUST add a Contact header field to the response.
Which means contact header mus
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Wednesday, July 09, 2008 8:03 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Is valid a retransmissions from
differentaddress:port ?
Hi, imagine a UAC
Generally, concurrent transactions is allowed in SIP.
There's some cases that you cannot do it.
i.e., Send INVITE when there's another pending invite transaction
sent/received.
RFC3261 14.1 UAC Behavior
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another
ck it out.
Besides that, since RFC3261 requires call-id and from tag creation
should be *unique*, so this would not be a big issue in real world.
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2008 5:54 PM
To: Rockson Li (zhengyli); [
yer at all.
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2008 5:30 PM
To: [EMAIL PROTECTED]; Rockson Li (zhengyli);
sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Re-invite without To Tag
I have a question here, th
ght be a out-of-dialog req for Core.
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2008 5:25 PM
To: Rockson Li (zhengyli); [EMAIL PROTECTED];
sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Re-invite without To Tag
I don't think so,
This request should be handled by core.
RFC3261 Sec 18.2.1
Next, the server transport attempts to match the request to a server
transaction. It does so using the matching rules described in
Section 17.2.3. If a matching server transaction is found, the
request is
RFC3966 gives some use-case of tel URI.
9. Use of "tel" URIs with SIP (Informative)
SIP can use the "tel" URI anywhere a URI is allowed, for example as a
Request-URI, along with "sip" and "sips" URIs. For brevity, we will
imply "sips" URIs when talking about SIP URIs. Both "tel" and S
I am a little bit confused here,
Two guys raised the same question before, unfortunately no any replies.
http://www.ietf.org/mail-archive/web/mmusic/current/msg03148.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg03416.html
FYI
Regards,
-Rockson
-Original Message-
From:
Inaki,
I think RFC3261 is not totally dependable for NAT transversal.
Symmetric respnse(RFC3581) must be adopted here.
-Rockson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Friday, July 04, 2008 11:42 PM
To: sip-implementors@
Alex,
I think a=sendrecv should be assume if no direction attribute specified.
As per RFC4566,sec 6
a=sendrecv
...
If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for s
I don't think it's required to have Event header in REFER, I think you'd
better not put it there.
Since as per RFC3515 sec 2.4.4
"The implicit subscription created by a REFER is the same as a
subscription created with a SUBSCRIBE request. "
The subscription is *implicit* created, not using su
1 - 100 of 118 matches
Mail list logo
