Re: [Sip-implementors] Transaction ACK route headers

[Dale R. Worley]

Filippos Vasilakis  writes:
> On the other hand, in RFC3665, section 3.11, does not copy the Route
> headers to the ACK and this is confusing. Seems like RFC3665 is in error,
> but again to me it seems that appending Route headers in a transaction ACK
> is pointless, since the final downstream transaction has already been
> ACK-ed by the middle proxy (like in 3.11 example in RFC3665).

It seems to me almost certain that F14 (the ACK from the client) in RFC
3665 section 3.11 is mistaken for not having the Route header (as you
point out).  It's probably just an oversight when writing the example.

In particular, F14 as written won't actually reach Proxy 1, since Proxy
1's address is ss1.atlanta.example.com (the address in the Route header
in the INVITE), not biloxi.example.com (the address in the To header).

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Call route advance standard

[Dale R. Worley]

Amanpreet Singh  writes:
> Peer is expecting the same call-id on the second trunk after route advance,
> was wondering if we have something around this to find a common ground to
> address this.

Please understand that this isn't a matter of standards compliance, but
a matter of the choices that the equipment on one side makes (within the
standards) and how well that interoperates with the choices that the
equipment on the other side makes (within the standards).

Although as another person said, it's very likely that your equipment
has a configuration option to cause it to use the same Call-ID for
forks of the same call.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Call route advance standard

[Dale R. Worley]

Amanpreet Singh  writes:
> I'm looking to see if there is any RFC defining the standard around route
> advance/ re-routing of calls to the next available route based on the SIP
> failure response.
>
> Looked into SIP Peering RFC6271 and RFC5486, however it doesn't cover the
> route advance requirements.

In regard to the SIP *specification*, a critical question is the nature
of the device that is forwarding the call onward and doing route
advance.  If it is sending outward INVITEs with the same Call-ID as the
INVITE it receives, it is a "proxy" doing "sequential forking", and the
requirements are in RFC 3261.  What changes the proxy is allowed to make
on the call as it passes through are relatively limited.

OTOH, if the outward INVITE has a different Call-ID, then the device is
a "back-to-back user agent" (B2BUA), and from the SIP point of view, it
is the UAS of the arriving INVITE and the UAC of the outgoing INVITE.
The SIP specifications place no limits on what a B2BUA may do, including
sending out what are effectively different forks of a call with
different Call-IDs.

A lot of telephony systems use B2BUAs rather than the SIP proxies that
were envisioned in the original SIP architecture.

> To be specific, we have SIP trunks with a provider, when a call fails on
> the first trunk with SIP 50X UAC is doing route advance to the next trunk
> with that provider as per priority. UAC is generating a new call-id in the
> INVITE for call to the second trunk; however the peer expects the INVITE
> with the same call-id.

There are two factors involved.  One is whether the device claims to be
a proxy, in which case it is required to use the same Call-ID on
different forks of a call that it handles.  The other is what the
trunking provider *requires*, which isn't necessarily limited by the SIP
specifications.  As a matter of good system architecture, I would expect
that alternative forks of one call would have the same Call-ID, so that
downstream devices can tell that they *are* alternative forks of one
call.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] 2 INVITE's: 491 answer -> 1 INVITE

[Dale R. Worley]

Alexandra Dias  writes:
> I need to know the structure of the Sip file in order to when simulating a
> inbound call we see 2 INVITE's arriving at the same time, with SIP
> response: 491 - Request Pending to one of then, but keeping the call
> running.

Are the two INVITEs attempting to begin the same dialog?  If so, the UAS
should respond to one of them with 482.  (See RFC 3261 section 8.2.2.2.)

If they are two re-INVITEs within an existing dialog, the UAS should
respond to one of them with 491.  (sections 14.2 and 21.4.27)

In either case, one of the INVITEs starts a transaction which continues
normally.

If the two INVITEs attempt to begin different dialogs, the UAS can
proceed in a number of ways.  One way is to respond to one of them with
486.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] How to differentiate Hold RTP and voice RTP

[Dale R. Worley]

Ranjit Avasarala  writes:
> Another way to check is the SDP.  for hold music,  the media attribute will
> be sendonly.  where as for regular voice traffic it will sendrecv

Yes, the "typical" way to tell that the far end has put you on hold is
that they will send you a=sendonly in the SDP.  Of course, that isn't
guaranteed to be done, but at least it is what people expect and many
systems conform to that.

In regard to trying to determine on-hold status from the RTP, that is
not reliable.  If you can detect that the far end is sending music, it
has likely put you on-hold.  But somtimes there are voice announcements
during on-hold.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] [SIPForum-discussion] RTP packet loss tolerance/ timers

[Dale R. Worley]

Amanpreet Singh  writes:
> I'm looking for the best practices to have minimum packet loss/ delays in
> case of primary network link failure. As the network secondary link takes
> about 3 seconds to come up.
>
> What best we can do on the application side to have the minimum RTP packet
> loss? Do we have timeout, retransmission timers for RTP, or any mechanism
> to adjust to minimize the loss. if not adjustable, default values based on
> which we can try changing network layer failover.

If you're sending real-time data, such as a two-way conversation, if the
link loses 3 seconds of data, you're going to lose 3 seconds of data.
Video and audio codecs use various tricks to cover up single packet
losses by synthesizing data to fill the gap in a way that avoids humans
perceiving the gap.  But there's no way to do that with a 3 second gap,
the recipient will notice.

If you're sending one-way data in near-real-time, and the major losses
are three-second gaps, you could send the audio data twice, with a
three-second offset between them.  A suitable decoder can patch the two
together to cover 3-second losses.  RFC 2198 gives a framework for
sending RTP packets that contain both a primary stream and a delayed,
redundant secondary stream.  But unfortunately, RFC 2198 specifies a
14-bit field to give the time offset between the streams, and with a
typical 8k/sec sample rate, the maximum value that can be specified is
2.048 seconds, which isn't long enough for your situation.

However, you could specify two separate RTP streams in the SDP, one of
which is the same packets as the other but transmitted 3 or more seconds
later.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] [SIPForum-discussion] RTP packet loss tolerance/ timers

[Dale R. Worley]

Amanpreet Singh  writes:
> We are working with our network team for audio/video traffic routing, some
> of the liks are not redundant and failover takes around 3 seconds to route
> the packets on the new link.
>
> I'm trying to understand if we have some standard timers defined (have gone
> through the RFC 3550 and 4585) for RTP but couldn't find.
> My understanding is, transport for RTP is UDP, which does not offer
> reliability and left upto the application to determine the packet loss and
> inform the user.

I haven't heard of any.  But could you provide some detail what the
usage would be of a timer that you're looking for?

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] question about RFC 8866 SDP

[Dale R. Worley]

massimiliano cialdi  writes:
> I would like to use a parser generator (like bison) or an SDP parser
> already written. Could you give me a suggestion?

Google gives me 400,000 hits for "sdp parser".  The first one is
https://github.com/clux/sdp-transform "A simple parser/writer for SDP".
There are likely to be others.

> bison supports yacc-type grammars (essentially a BNF). Do you know of
> a grammar translator from ABNF to BNF (even online)?

I don't know of one.  OTOH, translating ABNF into BNF by hand is simple
if you understand both.  And if you are going to do anything practical
with your parser, you will need to make minor modifications, which will
require that you understand well what your grammar is doing.

So I would start with studying the ABNF documentation (RFC 5234 and
possibly RFC 7405) and the Bison documentation.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sip From header without user part

[Dale R. Worley]

Rakesh  writes:
> I could see in a sip CANCEL message From Header as below
>
> From: "test" ;tag=3bbb9483d215d830c635372f8f181929
>
> is this correct?

To summarize what Paul has said:  Syntactically, this header is valid.
But usually the question is whether the entire SIP message containing
the header is valid, and that often depends on the context of all the
SIP messages which have come before.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] CSeq in subsequent Register messages

[Dale R. Worley]

Gilson Urbano Ferreira Dias  writes:
> Suddenly, the server decided to send CSeq = 1 in three consecutive Register
> messages for different Call-Ids.
> 
> I tried reading https://www.rfc-editor.org/rfc/rfc3261#section-12.2.1.1 and
> https://www.rfc-editor.org/rfc/rfc3261#section-8.1.1.5, but I'm still not
> sure if this is the expected behavior.
> 
> Could someone please clarify?
> 
> A--Request: INVITE  (Call-ID = A) (Cseq 932841)>B
> <--Status: 100 Trying   (Call-ID = A) (Cseq 932841)
> <--Status: 200 OK   (Call-ID = A) (Cseq 932841)
> ---Request: ACK (Call-ID = A) (Cseq 932841)>
> 
> <--Request: Register(Call-ID = B) (Cseq 1)-
> <--Request: Register(Call-ID = C) (Cseq 1)-
> ---Status: 200 OK   (Call-ID = B) (Cseq 1)->
> <--Request: Register(Call-ID = D) (Cseq 1)-
> ---Status: 200 OK   (Call-ID = C) (Cseq 1)->
> ---Status: 403 Forbidden(Call-ID = D) (Cseq 1)->

The crux is that all the REGISTER messages with a given Call-ID value
form a "pseudo-dialog" in that they don't form a proper dialog, but they
are all associated, in sequence, regarding *one* registration binding.
A consequence is that if two REGISTER messages have different Call-IDs,
they are not related, and the fact that they have the same CSeq is of no
matter.

You have not described what AORs the various REGISTER pseudo-dialogs are
for.  What you describe would be the common behavior if the three
pseudo-dialogs were for different AORs.

The 403 response for Call-ID D most likely has to do with the
authentication presented in the REGISTER for Call-ID.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] fmtp is missing in the retransmitted 200ok

[Dale R. Worley]

Anusha Muralidhara  writes:
> I have a scenario where in ACK from the callee is not being received by the
> Freeswitch for unknown reasons. Hence it is retransmitting 200OK. But in
> the second 200ok message fmtp is missing.
> Can someone please explain why fmtp is not sent in the retransmitted 200 ok
> message ?

I assume you mean that the first 200 and the second 200 both have SDP,
but the SDP is different.  That is of course an error.  But it seems to
me to be an unlikely error, so one thing to verify is that the second
200 is actually a resend of the first one and not part of some other
dialog.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Troubleshooting an ACK

[Dale R. Worley]

onewhoknows  writes:
> I have a UAC sending an ACK for a 200OK (re-INVITE) to a proxy that never
> gets to the UAS, this is what the ACK looks like:
>
> ACK sip:1000@10.69.69.70:5061 SIP/2.0
[...]
>
> The ACK goes to the proxy and goes no further, so the 200 OK from the UAS
> keeps re-transmitting until the call drops.
>
> I'm trying to determine if the formatting for the ACK is incorrect or not.
> The original re-INVITE does have route headers, the ACK above as you see,
> does not.

The most likely problem is not that the ACK is incorrectly formatted per
se, but rather that the proxy judges it is invalid within the
already-established dialog.  And there's no way to tell that without
seeing the re-INVITE and the 200 response.

You should check whether the proxy logs (or can be adjusted to log)
information about the dropped ACK.

Looking at RFC 3261, section 13.2.2.4 is about constructing ACKs in
response to 2xx responses, and it references section 12 for how to
construct requests within a dialog, specifically 12.2.

12.2 says "The UAC uses the remote target and route set to build the
Request-URI and Route header field of the request."  Since the re-INVITE
has Route headers (which presumably duplicate the Route headers of the
INVITE which established the dialog), this means that the ACK must have
the same Route headers.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RFC 3261 section 14.2 - "brand new call" does not specify whether the SDP should modify media attributes of an existing session containing a=sendonly or a=recvonly

[Dale R. Worley]

Shaun Stokes  writes:
> The problem occurs when the 3rd party sends an SDP with the media
> attribute 'a=sendonly' on an existing session then follow with a
> RE-INVITE with-out an SDP, they claim that our 2xx offer in response
> should contain an SDP with-out 'a=sendonly' (or replace with
> 'a=sendrecv') based on the interpretation of a "brand new call" used
> below. Anthony Minessale II (FreeSWITCH lead) claims that "brand new
> call" is only intended to refer to codecs (not all media attributes)
> and that the 3rd party (Broadsoft) invented this concept on their own.

You aren't providing a very clear description of the specific sequence
of events.  But I don't think that matters.  There are general
principles which clarify many situations.

The first principle is that the standards allow devices a wide range of
behaviors, and many allowed behaviors are not very useful in practical
systems.  In the case of providing SDP within an existing dialog, there
are specific rules that a particular media stream (a sequential m-line
in the SDP) may not change its media type, and codec numbers should not
be assigned to different codecs.  But there is no MUST about e.g. what
directional attributes must be supplied.

The second general principle is that when a UA provides an offer, it
should (but not must) offer all the communication possbilities it is
willing to support (at that moment).  Adhering to this maximizes the
chance that the two UAs will agree on SDP that allows useful
communication.

A third general principle is that when a UA receives an answer, it must
be prepared to receive any subset of what it offered, and make the best
of it.

A fourth general principle is that when a UA receives an offer, it must
be prepared to receive pretty much anything (within the few rules that
apply to offer/answer generally), and provide an answer which is some
subset of the offer.

If you want a more detailed analysis, you'll have to provide a skeleton
of an actual message exchange.  And for that matter, a clear statement
of what you don't like about the situation.

One item I notice in your text, and I cannot tell whether it is simply a
typo, is that you speak of the far endpoint sending SDP with a=sendonly,
that is, media coming to you but not from you.  Then you speak of the
near endpoint sending SDP with a=sendonly, which means, media coming
from you but not to you.  If the near endpoint was attempting to repeat
the current status of the media session, it would send a=recvonly.

As stated, the offer by the near endpoint is a=sendonly, and if the far
endpoint is in a state where it is only willing to send media, the
answer must contain a=inactive.  That leaves a state that is
standards-compliant, but probably not useful.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query on SIM swap

[Dale R. Worley]

Ranjit Avasarala  writes:
> Does SIM swap procedure on a SIP UE trigger re-registration?  if not when
> calls are made from the device, the INVITE would have the IMSI of the new
> SIM card?

The answers aren't set by the SIP standards.  However, given that the
SIM gives the Directory Number of a PSTN telephone, I would expect that if
you change the SIM on a UE, the UE would register for the new DN.

In SIP, the From address in an INVITE is not necessarily connected with
any AOR that the UE registers for.  But in a PSTN telephone, I would
expect it to use the SIM's DN as the From URI.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Proxy handling of in dialogue request

[Dale R. Worley]

Jason Harrison  writes:
> I ask as I have a proxy server that does not route a BYE request and I
> am trying to understand why

The answer to that is that if you post the message sequence (as seen by
the proxy), we may be able to help you.  But the devil is in the
details, there's little general advice we can give you.

One exception is that if you can see re-INVITEs successfully passing
between the UAs, usually when a call is put on-hold.  In that case, you
can compare the (successful) re-INVITES to the (unsuccessful) BYE.

> I know that a UA uses the remote target and route set to build the
> Route headers and request URI. What I cannot find detail on is how a
> stateful proxy will determine where to route the request.
>
> Does the proxy have a remote target and route set like a UA, or does
> it simply use the request URI.

The *dialog* has a route set and remote target.  When the UAC (sender)
of a particular request within the dialog sends a request, it loads
those into the message.  When a proxy receives the message, it looks at
the top-most Route header (if that exists) or the request-URI and uses
that to decide what to do.

One case is if it doesn't have any particular information about the
domain in question, in which case, it sends the message onward based on
the domain part of that URI.

Another case is if the domain in question is its own domain name, so it
remmoves that Route header and uses the next Route header (or
request-URI) to forward the message.

The other case is if it is "authoritative" for the domain, which usually
means that it is the registrar-proxy (i.e. switch) for URIs in that
domain.  In that case, it removes URI and replaces it with the contact
URI of the UA for the original URI.

All of these cases end with the message being sent onward based on the
domain-part of the URI.  See RFC 3263 for all the gory details of that.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] requirement to play media stream while on hold?

[Dale R. Worley]

Paul Heitkemper  writes:
> If you are placed on hold (a=sendonly), and the holder sends you a
> media stream, are you required to play it? I looked through RFC's
> 3261, 2327, and 3264, but I don't really see a requirement to actually
> play a media stream ever- when on hold or not.

That's right.  Indeed, there is essentially no specification of how a
SIP endpoint connects the RTP media streams to the user interface.  But
it might be difficult to sell a phone that will not render
media-on-hold.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SDP version

[Dale R. Worley]

"Sundbaum Per-Johan (Telenor Sverige AB)"
 writes:
> What do you think about incrementing the version in SDP o-line, but
> not changing anything else in SDP, should such a behavior be accepted
> or should it be rejected ?

There are two similar but distinctly different questions that you might
be asking.

The general principle is "Be conservative in what you produce and
liberal in what you accept."

If the question is, "Should a device increment the version in an SDP
o-line but not change anything else?", as you note RFC 4028 says that a
device should not do that.

If the question is, "If a device receives SDP with an incremented
version in the o-line that is otherwise identical to the preceding SDP,
should it reject it?", the device should not reject it.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Proposal for a mew SIP 4xx Error code

[Dale R. Worley]

Paul Kyzivat  writes:
> On 10/29/19 12:05 AM, Ranjit Avasarala wrote:
>> Currently, in all the above cases the SIP Proxy server that receives the
>> request, responds with a 400 Bad Request.
>> Though 400 Bad Request is acceptable given that there is some issue in the
>> SIP request, a more detailed error would be more useful - as sometimes
>> interpreting 400 Bad Request is harder
>
> You can use the Reason-Phrase in the 400 response to clarify what you 
> are complaining about. This should be sufficient to help a developer to 
> diagnose the issue and fix it. It won't be sufficient to all a 
> preprogrammed reaction in the UAC, but I don't see that as a reasonable 
> expectation for problems like this.

I would suggest using the Warning header with warn-code 399 and
reporting the problem in the warn-text.

The problem in practice is that this sort of error is not particularly
common once a system has been shaken down in production use.  And it's
really hard to provide any sort of automated reponse that is useful,
because there are so many possibilities.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] PSTN parameters in the FROM INVITE

[Dale R. Worley]

Zuñiga, Guillermo  writes:
> I was trying to look for information about what means the numbers that
> appear in some cases in the FROM header of the INVITE with the
> following (pstn-params=8084818088).
> 
> From: ;tag=SDh25j501-gK0a3ed144
> 
> Could you help to identify where I can get information about this?
> Cause in some case numbers are differents.

I've never seen it before.  A search only turns up an assertion that it
can be included in INVITEs by Sonus SBCs:

https://support.sonus.net/display/SBXDOC61/Sip+Headers+And+Parameters+-+Flags

"If enabled, the SBC includes a set of specific PSTN parameters in a
pstn-params= entry in outgoing INVITE messages. The PSTN parameters
currently included in pstn-params are Screening Indicator, ISDN
Indicator, and Transmission Medium Requirement (TMR). The options are:"

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] renegotiate rtp <--> srtp in mid call

[Dale R. Worley]

J C Sunil Kumar Reddy  writes:
> Can we renegotiate a rtp call to srtp and vice-versa in midcall? May be
> with re-INVITE or UPDATE message? Is it a valid scenario if srtp is not
> mandated?
>
> In my scenario, server and client both supports RTP and SRTP and initially
> call is negotiated to srtp call. Midway, server is sending a re-INVITE
> asking to change to RTP.  What should client do in this case? Accept, as
> SRTP is not mandatory or drop the call?

The most relevant RFC is 3264, section 8, "Modifying the Session".  It
is permitted for either endpoint to request to modify the session.
Whether it does this by re-INVITE or UPDATE does not matter.  As 3264
says, almost any aspect of a media description (an "m-line section" of
the SDP) can be changed.  My memory is that the only part that cannot be
changed is the media type, e.g., "m=audio", "m=video".  In particular,
the "transport" (RTP/AVP, RTP/SAVP) can be changed.

The difficulty is that the other endpoint can always reject the change
for any reason it wants.  So although it is valid to request the change,
there is no assurance that the change will be accepted.

In general, you should avoid dropping the call if the remote end
requests something that that the UA does not want to act on.  There is
almost always a straightforward way to reject the request and the
requestor should handle this correctly.  Dropping the call should be
done only if there is evidence that the two UAs are no longer able to
continue communicating for some reason.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] NOTIFY and Record-Route

[Dale R. Worley]

David Cunningham  writes:
> I must say RFC 6665 4.4.1 does seem to make it clear that the route set in
> the NOTIFY should be used, and therefore it's incorrect that the
> re-SUBSCRIBE sends directly to the Contact address rather than using the
> Record-Routes in the NOTIFY. It's very helpful to have this knowledge as a
> reference!

But don't overlook the 2nd paragraph of section 4.3:

   Proxies that did not add a "Record-Route" header field to the initial
   SUBSCRIBE request MUST NOT add a "Record-Route" header field to any
   of the associated NOTIFY requests.

My vague memory is that while the passage of the first NOTIFY request of
a subscription creates the subscription usage, the intermediate proxies
are required to insert Record-Routes into it in exactly the same way
they inserted Record-Routes into the SUBSCRIBE.  In particular, when the
subscriber receives a 2xx response, it can act as if that subscription
usage has been created and be assured that it will handle the dialog
correctly.  Further NOTIFYs that it receives create other subscription
usages based on their contents.

If I understand your example correctly, it was taken at the subscriber.
I see that the 200 response to the SUBSCRIBE contains no Record-Route
headers, so none of the proxies in the path have chosen to insert
themselves into dialog.  However, the first NOTIFY contains two
Record-Route headers, which violate section 4.3.

It appears the subscriber has refreshed its remote target based on the
Contact header of the NOTIFY, which it is required to do.  But it has
not recorded the Record-Route headers from the NOTIFY, which should not
be there.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Authorization Header Values- vs REFER getting SIP 403 Authentication Failure

[Dale R. Worley]

Zuñiga, Guillermo  writes:
> Hi fellows,
> 
> I would like you can help me with the following doubt.
> 
> I am having a user is Registering ok to a Registrar Server.
> Seeing the authorization values I can see that we have the Authorization 
> Header wiht the following Authentication-URI value= sip:domain.com
> Realm = domain.com
> 
> But I am having a problem with REFER messages where the Registrar is sending 
> 403 Authentication Failure.
> Here I can see the Authorization header values are:
> Realm = domain.com
> Seeing the Authentication-URI value = sip:to-uri-user@dst-ipaddress
> 
> Could be the Registrar sending 403 cause the Authentication-URI should be 
> like the REGISTER value?
> Where I could find reference about the correct values of the Authorization 
> Header?

The standards do not prescribe what Authorization headers a server will
accept.

However, the usual practice is that the "uri" value has the form
"sip:UUU@DDD", where UUU is the user-part of the user's AOR and DDD is
the SIP domain, the "realm" value is the SIP domain, and the "username"
is UUU.  Of course, the "digest-uri-value" that is used in the
computation of the digest (RFC 3261 section 22.4) is the same as the
request-URI of the request containing the header (which is different for
different requests even if they originate from the same user).

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Expected UE behaviour in call forwarding scenario if audio port turns OFF-ON before call established

[Dale R. Worley]

Arun Tagare  writes:
> I have a doubt on client/UE behaviour on the below scenario.
> Can any please help me share any spec. on what UE behaviour based on the
> below scenario.
>
> 1. MO voice call to User-B
> 2. 183/180 received from User-B
[...]

It would help greatly if you provided more detail about the exact
actions that are involved, and which devices in the network are sending
this messages to which devices.  Also, it helps to spell correctly and
use complete sentences.

In your message, it's not clear what "MO" is.  Also, sometimes messages
are describes as "from User-B" and at other times, "from network".  At
what point in the network are we observing the message flow?

In many situations in SIP, the standards allow the devices a great
latitude in behavior.  This is especially true when the question is
whether a device should send CANCEL for an INVITE or a BYE -- in many
situations, a user agent may reasonably decide that it can perform no
useful communication, despite that it is participating in a valid SIP
dialog, and thus send a BYE to terminate the dialog.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Cancelling an INVITE which did not got provisional response yet

[Dale R. Worley]

AXE MSC  writes:
> After 4 minutes, handset replies back with TCP ACK. PCSCF then re-transmits
> INVITE and and gets 183 back from handset. However, because calling party
> side call was already cleared at 15th second, this is causing a ghost call
> for B party after 4 minutes of the original call.

It is true that the called party sees a ghost call.  But immediately
after PCSCF receives the 183, it should send the CANCEL for the call.
So if the delay was in the propagation of the INVITE to the handset, the
ghost call will be canceled quickly (from the point of the view of the
called party).

> Can PCSCF destroy the transaction at 15th second without sending the Cancel
> to handset? Later if handset comes with provisional response  then PCSCF
> can just reply back with SIP 481(transaction does not exist).

Depending on exactly how PCSCF generates the INVITE it sends, it may be
able to avoid keeping state information for the call after it is
canceled.  But it is still required to send a CANCEL to the called
handset as soon as it receives a provisional response.  However, it may
be able to know that it should send the CANCEL, and be able to construct
and send the CANCEL, without having kept state information about the
INVITE.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header

[Dale R. Worley]

Rakesh  writes:
> Can I just know on  INVITE request if I get the below characters then is it
> OK as per ABNF grammar?  Please note I am not asking about the header
> rather I need to know the correctness of the character that has appeared on
> INVITE request.

Looking at the hex dump that you provided:  It contains 43 bytes of FF,
followed by the following text, followed by CR LF:

X-BroadWorks-DNC: 
network-address="sip:+34937817016@mt;user=phone";user-id="937817...@mfe.telefonica.net"

That text looks like a header that might be used in SIP requests.  But
it is a non-standard header, you can tell because it starts with "X-".
It is probably defined by BroadWorks.  Without knowing how BroadWorks
has defined the header, and the operational environment in which it was
used, there's no way to know whether it is valid.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Reflection of non-registered SDP attributes

[Dale R. Worley]

It's a fascinating problem.  In a way, inserting a unregistered
attribute is forbidden, but any recipient is forbidden from objecting to
it.

OTOH, if the attribute is unregistered, you can't really say that the
endpoint using it in its answer is *wrong*, since there's no fixed
definition of the semantics of the attribute.  Perhaps the endpoint
simply means "I received CustomAttribute:GID in the offer."

I think the actual answer is to be clever, and to define CustomAttribute
in such a way that simply copying it into the answer unchanged can be
detected and ignored.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RFC 4585: Negotiation of feedback mechanisms

[Dale R. Worley]

Richard Shields  writes:
> Can the feedback mechanisms be renegotiated within an SDP session with
> new SDP offer/answer exchanges? Should there have been text added,
> such as "until the next offer", to the text in RFC 4858?

A good point.  I'm not an expert, but skimming RFC 4585, it does look
like when they say "media session", they mean only the part of a session
between one offer/answer exchange and the next (or end of the session).

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query about Content-Type when Content-Length = 0

[Dale R. Worley]

To follow up to Paul's message, the situation of an empty and/or missing
body is not well-specified in SIP, and a SIP parser should be careful to
"be liberal in what you accept".  In particular, if the observed or
specified content length is zero, it *might* be that there is no body,
or it *might* be that a body is present (of the type specified by
Content-Type), but its encoding has zero length (the significance of
which depends on the Content-Type).  If the processing of the message
would succeed under one or the other of these conditions, it should
succeed.

In addition, if the processing of the message does not require knowing
the contents of the body, it should succeed even if the body is
unexpected, has an unknown Content-Type, or is invalid for its
Content-Type.  (Although it seems reasonable to be stricter regarding
multipart types, and perhaps require that the multipart structure per se
is valid.)

I am reminded of the sipX system, which when genereating error
responses, would add a body of type message/sip, which was the request
that caused the error.  This allowed the UAC to see in the error
response what the request looked like at the point where the error was
generated.  We never found any UAC that failed because of the unexpected
body (since no defined error responses at the time had specified bodies).

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Switch not forwarding 200OK message

[Dale R. Worley]

Abhishek  writes:
> A --> Switch --> B
> All 3 nodes connected with SIP connectivity.

> A sending INVITE to B but does not contain Require:100REL. Switch
> forwards Invite to B but has Require:100REL.

> B responds with 180 without SDP, Switch forwards the same to A. B then
> sends 183+SDP, which switch sends to A. Then A sends 200OK which
---^
I assume you mean "B" here.

> Switch does not forward to A. B sends 200OK multiple times as per
> standard and Switch disconnects session at both the ends with SIP
> cause code 500.
>
> Seeking reason for such behaviour.

It appears that Switch does not recognize the 200 as being part of the
dialog.  There are innumerable reasons why this might happen.  It is
hard for us to provide any help if you do not provide the INVITE (from
Switch to B) and the 200 (from B to Switch) for some example dialog.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RTP with wrong payload

[Dale R. Worley]

Paul Heitkemper  writes:
> RFC 3550 Section 5.1 
>
> " A receiver MUST ignore packets with payload types that it does not
> understand." 

Though this rule is based on the payload type code, and not the
encoding.  The original post says only that the packets contain G.722
data, but if that data is marked with the payload type code that was
negotiated for G.711A, the recipient will try to decode it as G.711A.
Perhaps the recipient can determine that the data is invalid (as G.711A)
and discard it, but more likely it will decode it into some sort of
noise which it will present to the user.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RTP with wrong payload

[Dale R. Worley]

"Sundbaum Per-Johan (Telenor Sverige AB)"
 writes:
> Can someone help me getting a link to information regarding how a PBX
> should handle the case when for example the codec G.711A is agreed
> upon, but somehow there are a couple of G.722 packets received that
> have the same ports on UDP level, but clearly belongs to another RTP
> stream when you look at sequence numbers, timestamps and SSRC ?

There's no real definition of "clearly belongs to".  If a packet arrives
at a port, it is processed according to the usage that has been
negotiated for that port.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] REFER received before ACK, What to do!!

[Dale R. Worley]

karthik sasupalli  writes:
> I have a scenario, where the REFER to an INVITE is received before the ACK.
>
> There is a Desk Phone and a Call server. The call is initiated by the Call
> server.
>
> Desk Phone <-- INVITE <-- Call Server
> Desk Phone --> 180 Ringing --> Call Server
> Desk Phone --> 200 OK/SDP --> Call Server
> *Desk Phone <-- REFER <-- Call Server*
> Desk Phone <-- ACK/SDP <-- Call Server
>
> The dialogue becomes confirmed when ACK is received. But in this case, the
> REFER is received before ACK and hence it is received even before the
> dialogue is confirmed.

The first step is to isolate what the RFCs say about the situation.

Unfortunately REFER is rather under-specified and in practice has a
number of different usages
(https://datatracker.ietf.org/doc/draft-worley-sip-many-refers/).  But
RFC 3515 section 2 does say, in regard to REFERs sent within a dialog,

   Unless stated otherwise, the protocol for emitting and responding to
   a REFER request are identical to those for a BYE request in [1].

RFC 3261 seciton 15 explicitly allows a UAC to send a BYE within an
early dialog, which means that a UAS can receive a BYE within an early
dialog (i.e., before receiving ACK):

   BYE outside of a dialog.  The caller's UA MAY send a BYE for either
   confirmed or early dialogs, and the callee's UA MAY send a BYE on
   confirmed dialogs, but MUST NOT send a BYE on early dialogs.

Hence, it seems the RFCs envision that a UA may receive a valid REFER
after sending a 1xx response to an INVITE but before receiving the ACK.

The second step is to assess whether the stated rules need to be
adjusted to work well in practice.  Roman Shpount's reply discusses some
of the practical considerations.  One of the most important is:

> It is very often re-ordered by the network or proxies with
> request that starts the next transaction.

Even if the Server sends the REFER *after* the ACK, and there is no
guarantee that the network will deliver the REFER after the ACK.  So
you want to make the Desk Phone's behavior resistant to this network
behavior.  I.e., it should accept and act on the REFER if it arrives
before the ACK.

> According to RFC3515, the server should retry REFER (in case the response
> is any one of the below)
>
> Retry-After 404,413,480,486 o
>
> Retry-After 500,503 o
>
> Retry-After 600,603 o

I'm not sure of your meaning here.  If the Desk Phone does send an error
response with a Retry-After header, the Server might retry the request.
But I would be confident of that; it is not a behavior I've heard of.

> I have changed the code in Desk Phone, so that, when a REFER is received
> before the ACK is received, the Desk Phone responds with 603 Declined.
>
> The server should understand this 603 response and try to resend REFER
> after some time so that REFER is received after ACK.

Notice the pattern of what you've written:  "I have changed the code in
XXX so that ... .  YYY should ... ."

That is, you have decided that useful operation of your device, XXX,
depends on *somebody else's* device YYY doing what you desire.  Of
course, you have to depend on other devices behaving correctly, but as a
general rule, you should depend on that as little as possible.  "Be
strict in the behavior of your device, be liberal in the behavior you
tolerate in other devices."

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] 401 Unauthorized with Require Header?

[Dale R. Worley]

I'm almost certain that what you want is the mechanism Olle described,
that if the registrar supports the feature, then it it sends "Supported:
xxx" in the response to the REGISTER, and the CPE (UAC) determines
whether to activate the feature based on the presence or absence of
"xxx".

It might help if you describe what the feature is.  Depending on the
feature, there may be better places in the logic to decide whether it is
active that at the moment of registration.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] 401 Unauthorized with Require Header?

[Dale R. Worley]

Sreekanth  writes:
> I am going through the SIP RFC (3261) and couldn't find anything specified
> regarding the 401 Unauthorized challenge response from the UAS side during
> a registration.
>
> I wanted to confirm whether it is okay to add a *Require *header into this
> 401 Unauthorized message response.

What would be the point?  The concept of a Require header is "the UAS is
required to reject the request (420) if it doesn't understand the
option-tag".  If a *response* had a Require header, either the UAC
understands the option-tag and processes the response as normal, or it
doesn't understand the option-tag ... and then what does it do?  It
can't send a 420 response *to a response*.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Routing for BYE Vs Other messages

[Dale R. Worley]

Prasanth Sylvester  writes:
> A subscriber IMS calling B subscriber in CS; My CSCF is going a breakout
> call towards the MGCF to reach B;
>
> Via: SIP/2.0/TCP 1.1.1.1:port;branch=XYZ
>
> Record-route
> 
>
> MGCF has these values for sending the reply.
>
> 1/ MGCF has to send 100 Trying, 183, 180 , 200 towards CSCF; Will it use
> Via header here?

I assume that you mean that the 100, 183, 180, and 200 are responses to
the initial INVITE.  As always, the response to a request is routed
using the Via headers as they appear in the request when it reaches the
UAS.

> 2/ MGCF has to send a BYE; Will it use Record-route here?

Once the dialog is established, all requests sent by a UA within the
dialog (such as BYE) will be routed using the Record-Route headers as
the UA received it in the request or response which established the
dialog.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] is Contact Header Mandatory and could be anonymous in the INVITE

[Dale R. Worley]

> On Sat, Mar 3, 2018 at 7:33 PM, Dale R. Worley  wrote:
>
>> Zuniga, Guillermo  writes:
>> > I Access enviroment not PEER to PEER connection, CONTACT could be
>> > anonymous or always should be any valid uri-user?
>>
>> The Contact always has to be a valid URI.  However, that URI does not
>> have to be the AOR (address-of-record) of a customer; it just has to be
>> able to reach the UA (when used by the next proxy in the signaling
>> path).

There are a lot of complexities.  Certainly, the Contact has to be a
syntactically correct URI.  But there are various ways to avoid
divulging user-sensitive information.  See

3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J.
 Peterson. November 2002. (Format: TXT=54116 bytes) (Status: PROPOSED
 STANDARD) (DOI: 10.17487/RFC3323) 

5379 Guidelines for Using the Privacy Mechanism for SIP. M. Munakata, S.
 Schubert, T. Ohba. February 2010. (Format: TXT=52595 bytes) (Status:
 INFORMATIONAL) (DOI: 10.17487/RFC5379) 

5767 User-Agent-Driven Privacy Mechanism for SIP. M. Munakata, S.
 Schubert, T. Ohba. April 2010. (Format: TXT=23270 bytes) (Status:
 INFORMATIONAL) (DOI: 10.17487/RFC5767) 

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Offer/answer model in early media with forking

[Dale R. Worley]

Alex Balashov  writes:
> Due to the way the RTP relay works on the server side, this results in
> two different SDP offers from the two respective outgoing branches being
> sent back to the caller:
>
> 1. 183+SDP on branch #1.
>
> 2. 183+SDP' on branch #2.
>200 OK+SDP' on branch #2.
>
> I am not sure offhand whether this is a protocol semantics violation. On
> the one hand, RFC 3261 section 13.2.1 ("Creating the Initial INVITE") says:

As Paul says, the RFCs aren't so very clear about it, but each branch
has a separate to-tag and so is a different dialog, and each dialog has
a seperate state machine.  So the section 13.2.1 you quote applies to
each branch independently.

> Well, the first branch is disposed of with a 5xx reply. But the UAC
> cancels nothing, in spite of getting two different early responses
> from two different dialogs.

You should have mentioned the 5xx reply in your original message, as
that's how the first dialog ends.

> Oh, yes -- they're different dialogs, for sure. I just wasn't sure if
> that would nevertheless pose a problem for some low-budget UAs.

A lot of low-budget UAs handle many situations incorrectly.  Ultimately,
the answer is to avoid using them, because otherwise you're spending all
your time adjusting your software to try to figure out what the UA is
and avoiding its flaws.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RFC 6337, Section 5.3. Hold and Resume of Media

[Dale R. Worley]

Parveen Aggarwal  writes:
> I have below scenario
>
> 1. A Calls B with "sendrecv"
> 2. B holds call with "sendonly"
> 3. A holds call with "inactive"-- both A and B media direction is "
> *inactive" *now

Let's spell this out more clearly:

1. A offers "sendrecv" to B.  B answers "sendrecv".

2. B holds call:  B offers "sendonly".  A answers "recvonly".

3. A holds call:  A offers "sendonly".  B answers "inactive".

Note that in step 3, A wants to put the call on hold, so it is unwilling
to *send* but it is willing to *receive*.  However, B is unwilling to
send, so it vetoes media in that direction, leaving only "inactive".

Note the general principle that you can't describe what is happening by
simply saing "X holds call with ", you have to show both the offer
and the answer to understand the dynamics of the interaction.

> Now, If B receives re-invite without SDP what should be media direction
> attribute value
> "*sendonly"* or *"inactive" *in offer of 200OK

As others have noted, B should offer *everything that it is willing to
do*.  In this case, B still has the call on hold, so it is willing to do
"sendonly", as it is willing to send music-on-hold but isn't willing to
render any media that it receives.

Since A still has the call on hold, it will likely answer "inactive".

> *As per RFC 6337, Section 5.3. Hold and Resume of Media*
>
>If a UA has occasion to send another offer in the session, without
>any desire to change the hold status (e.g., in response to a re-
>INVITE without an offer, or when sending a re-INVITE to refresh the
>session timer), it should follow the "General Principle for
>Constructing Offers and Answers" (Section 5.1). * If it previously*
> *   initiated a "hold" by sending "a=sendonly" attribute or "a=inactive"*
> *   attribute, then it should offer that again*.  If it had not previously
>initiated "hold", then it should offer "a=sendrecv" attribute, even
>if it had previously been forced to answer something else.  Without
>this behavior it is possible to get "stuck on hold" in some cases,
>especially when a 3pcc is involved.

Note in the passage that you marked, "If it previously initiated a
"hold"...".  The use of "initiated" means "If it previously *offered*
a=sendonly or a=inactive ...".

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Media Port change during Hold/resume

[Dale R. Worley]

Parveen Aggarwal  writes:
> Is it a correct behavior to update audio media direction from recvonly to
> sendrecv and updating the Video port in same re-INVITE? (Any spec reference)

There are few limitations regarding the changes that a new offer can
propose.  Mostly, the number of m- lines may not decrease and the media
type of each m- line must remain the same.  If the update to the audio
m- line is valid when done alone and the update to the video m- line is
valid when done alone, both can be done together.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] is Contact Header Mandatory and could be anonymous in the INVITE

[Dale R. Worley]

Zuniga, Guillermo  writes:
> I Access enviroment not PEER to PEER connection, CONTACT could be
> anonymous or always should be any valid uri-user?

The Contact always has to be a valid URI.  However, that URI does not
have to be the AOR (address-of-record) of a customer; it just has to be
able to reach the UA (when used by the next proxy in the signaling
path).

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Codec Negotiation issue

[Dale R. Worley]

Rakesh  writes:
> SECOND CASE:
> * User B put in Hold User A
> * User B sends REINVITE with sendonly containing only EVS,
> * REINVITE arrives to User A with sendonly and it contains all the VoLTE
> codecsin the following order: AMR WB, EVS, AMR NB.
> * User A answer with 200 OK recvonly that contains only AMR-WB because is
> the first in the list and the call quality has degraded
>
> So is the codec negotiation in both cases OK I am asking since in one case
> call quality is OK and in other case call quality is NOK?

As Paul notes, some "middlebox" in the call is adding codecs to the
re-INVITE.  As such, it is prepared to transcode between EVS (to B) and
AMR-WB (to A).  It appears that it actually is doing the transcoding,
but the problem is that the transcoding is not done well.  According to
the rules of SIP this is acceptable, but of course, the customer
experience is poor.

Ideally, the middlebox should either be improved to do the transcoding
well, or not add AMR-WB as a codec when the original re-INVITE contained
only AVR.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Question regarding sip authentication and 401 challenge response at UE side

[Dale R. Worley]

Arun Tagare  writes:
> Since we have different types of SIP AUTHENTICATION procedures (MD5,
> AKAv1, AKAv2) suppose say network challenged to the UE REQUEST with
> either one of the AUTH in the 401 response.
>
> Now due to some reason response (to the challenge) got failed/not
> calculated.  Is there any provision to use other procedure to
> calculate the response (to the challenge).

No, that will not give any benefit.  The UAC cannot respond to a
challenge using any particular algorithm unless it has received a
WWW-Authenticate/Proxy-Authenticate header (challenge) for that
algorithm, because that header includes information (nonce, etc.) needed
to provide a valid Authorization header using that algorithm.

That is why the device challenging a request must provide
WWW-Authenticate/Proxy-Authenticate headers for all algorithms (and
domains) for which it will accept Authorization/Proxy-Authorization
headers.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Announcement not heard during early media

[Dale R. Worley]

Mayank Gupta  writes:
> 1) INVITE from UAC to UAS with SDP offer
> 2) Server replied with 183 and SDP answer (G.711 codec)
> 3) UAC sent PRACK
> 4) Now UAS sends 200 OK for PRACK
> 5) RTP packets start flowing for early media
> 6) Backbone core network supports BICC
>
> End user (User-A) is not able to listen the voice message in early media.
>
> Any pointers what may be the issue?

I'd check where the flow of RTP packets ends.  (You don't specify which
end is "User-A".)  That device is the one that is not doing its job.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] re-Invite after 488

[Dale R. Worley]

Alexey  writes:
> Do i am right that re-invite in NOT mandatory by standard to continue 
> call with previous established RTP session ?

You are completely correct.  As the text you quote says, "the session
continues using the previously negotiated characteristics."

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Diameter Details

[Dale R. Worley]

voip tester  writes:
> How is message   flow in Diameter protocol (cx/dx)  with message format .
>
> If you share trace logs, it would be very good for me to understand .

I would start by reading the Wikipedia page:
https://en.wikipedia.org/wiki/Diameter_(protocol)
The References of the page list a number of RFCs that define parts of
Diameter.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] 200 OK Retransmission

[Dale R. Worley]

onewhoknows  writes:
> I have an issue with some older releases of Asterisk talking to an Avaya
> PBX.
>
> I think there's a network issue somewhere, but in the meantime, I'd like to
> know which side is handling the following transaction correctly:
>
> Asterisk > Avaya
> Invite >
> < 100 Trying
> < 200 OK
>> ACK
> < 200 OK
> < 200 OK
> < 200 OK
> ... several more times
> < 200 OK
> < BYE
>> 200 OK
>
> The issue is intermittent and when it occurs, the far end does not see the
> ACK.
>
> My question in this particular instance is should Asterisk be responding to
> each 200 OK with an ACK, or has it satisfied its part of the transaction by
> sending that first ACK?  Each 200 OK has the same CSEQ, branch, etc.

Every 200 that the UAC receives, it must answer with an ACK.  See RFC
3261 section 13.2.2.4, "The UAC core MUST generate an ACK request for
each 2xx received from the transaction layer.", etc.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Reinvite/ACK race

[Dale R. Worley]

Alex Balashov  writes:
> On Tue, Oct 31, 2017 at 10:38:00PM -0400, Dale R. Worley wrote:
>> As others have said, the problem must be solved by the UAs, not the
>> proxy.  Indeed, what with possible network delays and re-sending of
>> lost packets, there's no way to guarantee end-to-end sequencing of
>> messages.  Even with TCP service, there's no guarantee that none of
>> the intermediate proxies aren't using multiple TCP connections to
>> carry messages between themselves.
>
> That's certainly true. But in this case I do control the entire setup
> topology end-to-end, and implicit in my thesis was the desire to assert
> control over that over which control can be asserted. :-) 

Well, I'd answer "the difference between theory and practice is larger
in practice than in theory".  If you can get what you want without
exerting special control over all of the parts of the system -- a
control which SIP is not designed to ensure you can have -- you're a lot
more likely to succeed.

> The scenario described in the foregoing is for a reinvite occuring after
> an *initial* INVITE cycle but arriving before the ACK for that initial
> INVITE. 
>
> The scenario I've got going on is a reinvite following another reinvite.
>
> As you suggest, there are few reasons to think that the reasoning
> should be different, or at any rate substantially different, for a
> consecutive reinvite vs. a reinvite following an initial
> INVITE. Nevertheless, that was what motivated the perception that
> [section] 3.1.4 may not speak to the fine letter of the exact scenario
> in play.

True...  But I wouldn't want to have to build a system that
distinguished the two cases.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Reinvite/ACK race

[Dale R. Worley]

Alex Balashov  writes:
> 5. UA B sends end-to-end ACK for reinvite #1 and almost
>simultaneously sends reinvite #2. The temporal delta is
>between reinvite #2 and ACK for reinvite #1 on the wire
>is 3 ms.
>
> The issue is that the concurrency characteristics of proxy P are such
> that its worker threads are very loosely coupled, and there's no
> synchronisation among them for message ordering. Transport is UDP,
> naturally.

As others have said, the problem must be solved by the UAs, not the
proxy.  Indeed, what with possible network delays and re-sending of lost
packets, there's no way to guarantee end-to-end sequencing of messages.
Even with TCP service, there's no guarantee that none of the
intermediate proxies aren't using multiple TCP connections to carry
messages between themselves.

> So, the result -- for all kinds of stochastic processing and userspace
> scheduling type reasons -- is that the reinvite is forwarded first,
> before the ACK.  That leads to a 500 / 491 scenario UA A.
>
> Is there any general guidance on what to do with these scenarios? I
> looked at RFC 5407 [section] 3.1.4, which appears to describe a
> similar, but not identical scenario involving an initial INVITE and
> subsequent reinvite.  As far as I can tell, the recommendation in that
> standard is "space the messaging out more in time".

You're correct to look to 5407 (which is important enough to be known as
just "Hasebe") for guidance.  And it does look like section 3.1.4 is the
relevant case, or very close to it.

   This scenario illustrates the race condition that occurs when a UAS
   in the Moratorium state [having sent 2xx but not received ACK]
   receives a re-INVITE sent by a UAC in the Established state.

And as the text goes on, sending 2xx is recommended, rather than 491,
because all of the state changes within the UA associated with the first
re-INVITE have already been completed.  But a 491 response is also
permissible.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Codec negotiation on SIP Referred-by

[Dale R. Worley]

Ivo Vastert  writes:
> What we try to do is the following scenario:
>
> Inbound call from: #gateway1 ==> #SBC1 ==> SIP client (Gateway offers
> G711alaw, G711ulaw and G729) SBC passes codecs as-is.
> Sip client has codec preference (G722, G729, G711alaw, G711ulaw)
> The SIP client accepts this call, (#Leg1, on G729)
>
> Then the SIP client makes a outbound call: SIP client ==> #SBC1 ==>
> #gateway2
> Sip client has still codec preference (G722, G729, G711alaw, G711ulaw).
> #Gateway2 has codec preference (G722, G711alaw, G729).
> #Gateway2 accepts this call on G722.
>
> So now we have the following situation:
> A SIP client with 2 legs, both going to #SBC1, where #Leg1 is on G729 and
> #Leg2 on G722.
>
> The SIP client sends a SIP REFERED-by to #SBC1 to connect the legs to each
> other.
> In this case there is a codec mismatch, but currently our SBC is still
> bridging the calls which results in bad audio because of a codec mismatch.
>
> What should be the behaviour of the SBC / B2BUA in this case?

The basic scenario is the one without the SBC in the middle:

gateway1 ---> SIP client (sets up dialog A)

SIP client ---> gateway2 (sets up dialog B)

Now, the client wants to connect the two legs, so it sends a REFER
within dialog A containing a Refer-To URI with a Replaces parameter.
This causes gateway1 to set up dialog C with gateway2.  Since this is a
new dialog, the gateways negotiate codecs from the beginning, so there
is no mismatch.

Introducing an SBC makes things a lot more complicated because there are
a number of ways an SBC could behave in this scenario.  Some involve the
SBC "passing through" the REFER in order to avoid including itself in
the new dialog C.

But not looking at those complications, we are in this state:

   dialog A1  dialog A2
gateway1 -->\
 \
  V
   SBCSIP UA
  /
   dialog B2  dialog B1  /
gateway2 <--<---/

If the SBC wants to continue dialogs A1 (from gateway1 to SBC) and B2
(from SBC to gateway2), then it needs to create a new dialog C to
replace A2 and B1, where both endpoints of dialog C are on the SBC, with
one endpoint being "connected to" A1 and one endpoint being "connected
to" B2.  Logically, this is the effect of the UA's REFER arriving at
SBC's end of A2, directing that endpoint connect with SBC's end of B1:

   dialog A1  
gateway1 -->\
 |
 |
   SBC   |  dialog C
 |
   dialog B2 |
gateway2 <--|
  |   ||
  |   |   200 OK   |
  |   |   SDP offer|
  |   |<---|
  |   ||
  |   re-INVITE   ||
  |   SDP offer   ||
  |<--||
  |   ||
  |   200 OK  ||
  |   SDP answer  ||
  |-->||
  |   ||
  |   |  ACK   |
  |   |  SDP answer|
  |   |--->|
  |   ||
  |   ACK ||
  |   no SDP  ||
  |<--|   

Re: [Sip-implementors] B2BUA behavior in correlation of Pre-Conditions & Multiple Early Dialogs

[Dale R. Worley]

VARUN BHATIA  writes:
> As a B2BUA what is the expectation when it is sitting behind a forking
> proxy (IMS Application Server) and it is sending back multiple early
> dialogs back.
>
> 1. It should ideally send it back transparently to ingress i.e.
> creating multiple early dialogs at ingress leg too. (UAC should be
> capable of supporting early dialogs)
> 2. Doing inter-working with ingress and rather than sending multiple
> early dialog toward ingress it should send new offer in UPDATE.
> (Though in this case UAC should support UPDATE method in early
> dialog).

As Paul said, the B2BUA must present itself as a proper UAS on the
ingress side and as a proper UAC on the egress side.  Other than that,
it can do anything that accomplishes your goal.

But as Paul also said, it is complicated to bundle multiple early
dialogs on the egress side into one early dialog on the ingress side.

> In the above scenario if Pre-condition is been expected then will
> there be any change or it should be same.
> As per my understanding forking proxy should handle, in this scenario,
> once the pre-condition has been exchanged & resource reservation has
> been done. AS should not send multiple early dialog towards B2BUA.

A forking proxy is simpler, because the proxy doesn't actually handle
any of the precondition processing, it just passes the messages
through.

A UAC that is handling preconditions on multiple early dialogs has to
allocate resources for each of them, in coordination with each early
dialog's precondition negotiation.

It would be complicated for a B2BUA to merge precondition processing in
multiple early dialogs into precondition processing in a single early
dialog, because the B2BUA would have to merge the demands of all of the
UASs into a single demand for reservations on the ingress side.
Depending on the range of demands that can be expressed in
preconditions, it might be difficult to create such "union"
preconditions.

> Though i am trying to find reference in RFC or 3GPP standard but not
> yet able to find any.

The difficulty is that the problem is implicit -- Can you figure out how
to implement a B2BUA that has the features you want?  The standards only
prescribe the requirements that the B2BUA must conform to, not how to
design one that does what you want.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Network Initiated De-registration

[Dale R. Worley]

Paul Kyzivat  writes:
> On 10/6/17 1:04 PM, Abhishek Jain wrote:
>> 1. Under what senarios or conditions, Network would initiate deregistration
>> to a UE ?
>
> The only reason that is covered by ietf sip standards is expiration of 
> the registration without renewal. Other reasons would be based on 
> policy. For instance, if the account for the AoR has beed deleted.

Thinking about it, I don't think that there's a general way for the
network to signal to the UA (UE) that it has been prematurely
deregistered, that is, deregistered before the expiration of a
previously granted registration.  Of course, once the proxy/registrar
isn't willing to route calls to the UA, it *is* deregistered, and of
course, it can refuse to accept calls originating from the UA.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] rules for From-tag generation in forking B2BUA

[Dale R. Worley]

Andrew Pogrebennyk  writes:
> I understand that there is no normative document for a B2BUA but in
> general as common sense dictates should the B2BUAs that generate
> multiple outgoing requests on their UAC side for a single incoming
> request due to parallel forking create unique From-tags or reuse the
> same From tag in every request (INVITE)? I have concerns over a SBC
> vendor that requires same From tag (else some overload prevention kicks
> in) because it looks like re-using From-tag (but having different Via
> branches of course) might trigger a loop detected response with some
> endpoints as per https://tools.ietf.org/html/rfc3261#section-8.2.2.2
> What is the best practice here?

There is at least this consideration:  The B2BUA can generate multiple
outgoing *dialogs* from one incoming request, acting as a UAC generating
multiple dialogs.  In that case, each outgoing request, each dialog, has
to have a unique Call-Id.  Each dialog has to have its own from-tag, and
taken collectively, the from tags have to be statistically random.  In
particular, you can't just use the same from-tag on each outgoing
dialog.

Alternatively, the B2BUA can (in principle) generate one outgoing dialog
(with its unique Call-Id and its from-tag) and then (as UACs are
allowed) immediately fork it to multiple destinations.  So what you see
on the wire is multiple outgoing requests with the same Call-Id, the
same from-tag, and different Vias.

In the second case, any UA downstream can recognize that if it receives
requests coming from more than one of these forks, it can reject all but
the first.  But that shouldn't cause any problems in practice.

So the only thing that shows up as a rule is that the B2BUA has to be
consistent whether its outgoing requests are forks of one dialog, or
separate dialogs; that is, if the Call-Ids are the same, the from-tags
must be the same, and if the Call-Ids are different, the from-tags
should be randomized.

There is a third case, the B2BUA which is trying to pretend it is a
proxy, or "quasi-proxy".  But those always use the same Call-Id and
from-tag on their outgoing requests as was present on the incoming
request.

Now it's possible that the downstream equipment you are referring to has
some narrow rules that interact badly with one of these modes of
operation.  I suggest you get a clear description of the mechanism that
is involved and report back about that.  Then we might be able to
clarify the choices.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Should CANCEL request include the Route set from a reliable 18X

[Dale R. Worley]

neil corcoran  writes:
> We then send CANCEL in accordance with
> https://tools.ietf.org/html/rfc3261#section-9.1
>
> we send this to the same destination as the original INVITE and don't
> include the Route headers or from the 183

The concept is that the CANCEL is a follow-up or "second half" of the
INVITE, it's not a later transaction (which might be affected by the
responses that the INVITE received).

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] In-Dialogue

[Dale R. Worley]

"Verma, Salil (Nokia - IN/Noida)"  writes:
> While checking SIP calls , sometimes I see INVITE messages indicated
> with "in-dialog". What does that mean?

An in-dialog INVITE, or re-INVITE, is an INVITE request sent within an
existing dialog.  This can be done for a number of reasons, one of which
is to modify the media streams being sent/received.  Section 14 of RFC
3261 gives an overview of the use of re-INVITE.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Contact header URI comaprision

[Dale R. Worley]

Paul Kyzivat  writes:
>> Contact: "" 
>> 
>> Contact: "" 
>> 
>
> What leads you to this conclusion? Parameter order is never relevant.

Specifically, a little earlier in section 19.1.4 is:

  o  The ordering of parameters and header fields is not significant
 in comparing SIP and SIPS URIs.

>> I am facing an issue on which the contact URI comparison has happened and
>> it fails due to the TRC parameter not in order which I guess so far.

By the rules of 3261, these two URIs are equivalent.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Is it possible to fork early media?

[Dale R. Worley]

Rodrigo Pimenta Carvalho  writes:
> For example,  when user U1 calls and his call is forked (parallel
> fork) to users U2 e U3, if there is early media negotiation between
> the caller and the callees, can U1 keep the media stream with U2 and
> U3 simultaneously?

It is possible, the establishment of media between the caller and each
callee is independent.

The difficulties are how to recognize the situation and how the caller
can handle it.  The caller will usually see the two media streams coming
from different IP addresses/ports.  Usually, the source addresses of the
streams correspond to the addresses given in the SDP the callees send,
but not always.  And the media may start arriving at the caller before
the SDP arrives.

In a perfect world, the caller would test each media stream for whether
it is "silent", and then all of those that are not silent would be mixed
for presentation to the user.  (Humans can usually parse multiple audio
sources.)  If an early dialog receives a 18x response but there is no
media stream that can be matched with that callee, it may be valuable
for the calling UA to include an appropriate audio signal in the mix --
a ringing tone for a 180, a forwarding tone for a 181, etc.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sending deRegister request just after sending REGISTER request

[Dale R. Worley]

Paul Kyzivat  writes:
> Another consideration is whether these are done using the same Call-ID. 
> (In the same pseudo-dialog.) I don't think it will generally make any 
> difference, but it may present issues if you are also requesting a 
> temporary gruu with the registration.

I haven't dug through the specifications.  But if they have the same
Call-ID, then the CSeq tells the order the REGISTERs are to have
effect.  If the network reorders them, the de-REGISTER will prevail
because it has a higher CSeq.

   A UA SHOULD use the same Call-ID for all registrations during a
   single boot cycle.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SIP Bye before 200 OK for Initial Invite

[Dale R. Worley]

NK  writes:
> I am facing a strange scenario where my SBC is sending BYE before it
> received 200 OK for initial invite.
>
> A = INVITE > B
> A <=== 100 Giving a Try B
> A <==100 Try B
> A <==183 w/SDP==B
> A <==183 w/SDP==B
> A <==180 w/SDP==B
> A = *BYE* ==> B
> A <=== *SIP 200 OK for Invite* B

I take it that "my SBC" is the same as "A"?  You really should use
consistent terminology, or explain this.

> Anyone faced this problem earlier? Is that possible because i believe we
> should receive only CANCEL to terminate the call before the dialog
> establish.
>
> Can any one please help on this? And if there is any rfc can help me to
> understand this.

It looks like the first paragraphs of section 15 of RFC 3261,
"Terminating a session", address this.  The critical point is that while
the UAC sending CANCEL attempts to terminate the effect of the INVITE,
that is, all active forks of it, a BYE terminates only the *dialog or
early dialog* it is sent on.  That is, a BYE has a to-tag, and it only
affects the (early) dialog with the UAC that sent the (provisional)
response(s) with that to-tag.

So to address your case, you'd need to specify what to-tags are present
in the responses.  I suspect that all of them have the same to-tag, so
there's one early dialog starting at the first 183 that would become
established with the 200 for INVITE, but it's terminated by A sending
the BYE.

As always, when dealing with strange cases of the SIP protocol, it's
worth checking RFC 5407, "Example Call Flows of Race Conditions", which
is so significant it is sometimes referred to by just the name of its
primary author, "Hasebe".  It gives more detailed state machines for the
UAS and UAC.  In this case, I find "Appendix A.  BYE in the Early
Dialog", whose text refers to section 3.1.3, "Callee Receives BYE (Early
State) While in the Moratorium State".

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handling of message cross over between 200OK(INVITE) and 200OK(PRACK)

[Dale R. Worley]

Dinoop  writes:
>UAC  B2BUA UaB
>   | 1:INVITE(SDP)  ||
>   +--->||
>   |   2:100[INV]   ||
>   |<---+|
>   || 3:INVITE(SDP)  |
>   |+--->|
>   ||   4:D1.183[INV](SDP)   |
>   ||<---+
>   |   5:D1.183[INV](SDP)   ||
>   |<---+|
>   |   6:D1.PRACK   ||
>   +--->||
>   ||   7:D1.PRACK   |
>   |+--->|
>   ||   8:D1.200[INV](SDP)   |
>   ||<---+
>   || 9:D1.200[PRA]  |
>   ||<---+
> 
> 
> Where the 200[INVITE] has reached B2BUA before 200[PRACK]. What should be
> the behavior of B2BUA as Ua-Client on right side. Or in general what
> handling should be done at Ua-client side when this occurs?. Is there any
> standard defined to handle this message crossing?

It seems that the key to this is in section 3 of RFC 3262:

   The UAS MAY [...] unless the final response is 2xx and any of the
   unacknowledged reliable provisional responses contained a session
   description.  In that case, it MUST NOT send a final response until
   those provisional responses are acknowledged.

UaB follows this rule, because message 4 is acknowledged (UaB receives
message 7) before UaB sends the 200 (message 9).  Similarly, at the
end of this sequence, B2BUA can send a 200 for message 1, having
received message 6.

Reading this section, it doesn't seem that there is any constraint
regarding when a UAS has to send 200 for PRACK compared to any other
messages.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handling of message cross over between 200OK(INVITE) and 200OK(PRACK)

[Dale R. Worley]

Dinoop  writes:
> How can a B2BUA handle message crossing of 200OK(invite) over 200OK(PRACK)?
> Is it a correct approach  for the implementation to reject the
> 200OK(INVITE) until it receives PRACK response?
>
> I have gone through the RFC 6337, unfortunately nothing is mentioned about
> this scenario.

As Paul says, the B2BUA has to behave correctly "on each side".  In your
situation, we would need to see a detailed diagram of the message flow
you are contemplating before we would know exactly what the situation is
and what possible strategies the B2BUA could use.
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Early Media and 200 OK with SDP

[Dale R. Worley]

Anjan Naik  writes:
> Could anyone look at the below scenario and let me know expected behavior
>
> 1) INVITE from Client to Server with Supported: 100rel
> 2) Server replied 1xx with Require: 100rel and RSeq with SDP
> 3) Client sent PRACK with SDP
> 4) Now 200 OK for PRACK received from Server
> 5) Now 200 OK for INVITE came from server with SDP
>
> Do Client has to send SDP in ACK ?

The important specifications are RFC 3262, and sections 13.2.2.4 and
13.3.1.4 of RFC 3261.  You can also look at Example 2 in section 3.1.2
of RFC 6337.

I'm not sure about this case, but the text in 6337 says that the offer
in the 1xx (2) should not be duplicated in the 2xx (5), but that some
UASs do duplicate that offer, and if so, the UAC should ignore it.

It doesn't seem that the standards envision that the offer in the 2xx
(5) could be different from that in the 1xx (2).  That would require
that (5) starts a new offer/answer exchange.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Duplicate RTP streams with same source IP address and Port number

[Dale R. Worley]

Ramesh Kuppili  writes:
> I have a situation where I am receiving multiple RTP stream from the 
> same IP address and port number.  But with different SSRC. The media in 
> the both streams is the same (audio, more precisely ringback tone).  How 
> should I handle this scenario.

Here is one complication:  Your system probably doesn't know when this
scenario is happening and when it is not happening, because your system
probably doesn't want to expend the effort to recognize when "The media
in the both streams is the same".

Thus, in practice, the question is, "I am receiving multiple RTP stream
from the same IP address and port number.  But with different SSRC.
What should I do in this situation, such that in the specific case when
I receive the same media (ringback tone) via both SSRCs, there is still
a good user experience."

Actually, if your system is receiving two copies of the same media under
different SSRCs, I would say that the sending system is malfunctioning.

The typical implementation during an early dialog is to mix all incoming
audio streams.  In addition, if one of the early dialogs is ringing (has
returned a 180 Ringing status but not a 199 Early Dialog Terminated) and
no non-silence audio is being received from that endpoint, the
implementation adds a locally-generated ringback tone to the mix.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Receiving 481 Call Leg Transaction does not exists for INVITE with Reliable Provisioning

[Dale R. Worley]

Harshith Mulky  writes:
> I am attempting a call where I am expecting PRACK after INVITE.
>
> But once I receive PRACK, I am getting a 481 Call Leg Transaction does
> not exists
>
> I have attached the Logs,

It looks like the logs have been removed by the mailing list
processing.  You will have to extract the messages and quote them in
your message.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] What is being rejected here?

[Dale R. Worley]

Brett Tate  writes:
>> I've been scratching my head all day comparing branch branches, tags,
>> and call-ID's and I can't seem to pinpoint it.
>>
>> Does anyone have any suggestion what I (or SIPp) might be doing wrong?
>
> The request-uri within the ACK and BYE were not updated to reflect 2xx's
> Contact sip-uri.  However, I'm not sure if that was truly why the BYE was
> rejected with a 481.

I'll echo Brett here, it looks like the target URI on the BYE is
incorrect and the UAS is within its rights to not recognize what dialog
the BYE is within.  RFC 3261 section 12.1.2 says "The remote target MUST
be set to the URI from the Contact header field of the response."

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query on SIP REGISTER refresh dialog

[Dale R. Worley]

Puneet Kumar  writes:
> If a UA uses different dialog-ID(say new Call-ID & No To header tag)
> for REGISTER refresh with same contact address then it is allowed?
> If not then please point out RFC section which blocks a UA from doing it.
>
> In general does REGISTER refresh & REGISTER for deregistration MUST be
> in same dialog as earlier REGISTER?

To echo Brett, the sequence of REGISTERs sent by a UAC don't form a
dialog.  (You might consider each individual REGISTER a seperate dialog
containing only one request.)  But since they have the same Call-Id and
increasing CSeq's, they form a series that in some ways resembles a
dialog, that can be called a quasi-dialog or pseudo-dialog.

To understand what a UAC should do and the exact effect of a set of
REGISTERs, you have to study exactly how RFC 3261 section 10 specifies
that REGISTERs are processed by the registrar.  And if the "SIP
Outbound" extension is being used, RFC 5626.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query regarding

[Dale R. Worley]

Rohit  Jain  writes:
> I have a customer that has A PBX that sends a 200 OK with a 200 OK with the
> PAI Header (with CRLF on two lines):
>
> P-Asserted-Identity: "Blumenberger Jr
> n" 
>
> instead of
>
> P-Asserted-Identity: "Blumenberger
> Jrene

It appears that your examples were damaged in transit.  However one
thing I note is that the second example contains an un-matched
double-quote character, which is not valid.

The central rule of a multiple-line header is that the CR-LF must be
followed by whitespace (SPACE or TAB).  Exactly where CR-LFs may appear
in a header is determined by the ABNF for that header.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RFC 7463: PUBLISH with To tag question

[Dale R. Worley]

Brett Tate  writes:
> Some of the PUBLISH examples within RFC 7463 (sections 11.7, 11.9, 11.10,
> and 11.14) contain a To tag.
>
> Was that was intentional?
>
> RFC 3903 does allow PUBLISH to be sent within dialog.  However, I'm not
> sure what within RFC 7463 is actually creating the dialog that is being
> shared unless maybe sharing dialog with depicted NOTIFYs (and according to
> section 11.7 example, that is not occurring).

The example messages are not well-organized.  The to-tag on those
PUBLISHes is 428765950880801, which appears only on the 4 PUBLISHes that
have to-tags.  Since PUBLISH cannot create a dialog, there would have
had to be some other request that created the dialog with that to-tag.

Three of the PUBLISHes have to call-id 87837Fkw87asfds, and one has the
call-id 44fwF144-F12893K38424, all of which appear only in PUBLISHes.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SIP Request URI Domain processing without Port

[Dale R. Worley]

Varadhan Work  writes:
> Suppose,
> SIP Domain name: *mydomain.org *
> SIP Port: *8060*

> Question is,
> If Req-URI received [by the Registrar] without port number on SIP
> server listening port 8060 as follows,
>
> *REGISTER sip:mydomain.org  SIP/2.0*
>
> a) Can domain name without port number, should be allowed for the same 8060
> port routing ?
> and
> should be manipulated based on received(socket) port number ?

The standards do not truly fix the behavior in this case, because the
Registrar that receives the message is allowed considerable latitude
regarding what bindings it records and what their meanings are.  But in
general, Mohit Soni's answer is the best practice:  sip:mydomain.org is
a different domain from sip:mydomain.org:8060 and the Registrar for
sip:mydomain.org:8060 should either reject this message or forward it to
sip:mydomain.org.

The particular situation where this behavior is needed is if the host
mydomain.org has two SIP systems, one listening on port 5060 using
domain sip:mydomain.org and one listening on port 8060 using domain
sip:mydomain.org:8060.  In that situation, the two systems should
operate independently, and that requires that both of them are strict
about handling REGISTER messages.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SIP Domain with single part

[Dale R. Worley]

wor...@ariadne.com (Dale R. Worley) writes:
> However, there has
> been at least one exception:  Fredrik Thulin once managed the nameserver
> for .SE and added an MX record for .SE, directed to the host that
> handled his e-mail.  Thus,  was a valid e-mail address for
> him.

Thinking more about this, I think I was incorrect, and that Fredrik's
e-mail address was instead .  (Back in the days when hosts had so
few users that one's initials were unique.)  Which will probably hold
the record for shortest valid e-mail address for all time...

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SIP Domain with single part

[Dale R. Worley]

Varadhan Work  writes:
> Is it legal to have SIP domain name in SIP packet with only one single part
> without top level domain name ?

In both the general domain name syntax and in RFC 3261, section 25.1,
production "hostname" you can see that a domain name with only one label
is syntactically *legal*.  So SIP URIs with such a domain name are
legal.

It is unlikely that such a URI will be usable, because it is rare that a
domain name with only one label has any DNS records defined for it
(other than NS and other DNS structural records).  However, there has
been at least one exception:  Fredrik Thulin once managed the nameserver
for .SE and added an MX record for .SE, directed to the host that
handled his e-mail.  Thus,  was a valid e-mail address for
him.  Similar uses could be arranged for SIP.

In addition, in many situations, there is a convention that a domain
name that does not have a trailing "." will be passed to the DNS
resolver to search for using a provisioned list of suffixes.  E.g., in a
host xyz.example.com, the suffix list may be "example.com" and "com",
allowing "abc" to be used to look up DNS records for abc.example.com.
In these situations, the trailing "." suppresses the lookups with
attached suffixes.  In the case of SIP, the syntax allows the use of a
trailing ".":

hostname =  *( domainlabel "." ) toplabel [ "." ]

However, I've never heard of a SIP system (intentionally) allowing the
use of provisioned suffixes in DNS lookups under any circumstances, and
skimming RFCs 3261 and 3263, I don't see any indication that it was
intended to allow it.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Question about RFC 3398- Ring back Tone and One Way Audio Issues.

[Dale R. Worley]

Zuñiga, Guillermo  writes:
> Hi Fellows,
> 
> I am having  the following issue with one device that is having one way audio.
> 
> The Calls is from a SIP UA to PSTN site, when the call is stablishing
> the only way I have audio in both ways is when in the following case:
> 
> UASBC/GW->PSTN
> INVITE->
> TRYING<
> 183 W/SDP<
> RTP(RBT)<---
> RTP--->(LIKE SILENCE FROM UA)
> 200OK<--
> ACK--->
> RTP<>RTP IN BOTH WAYS

You should note that the INVITE contains SDP, because a UA can send
an INVITE without SDP.

> Could you help me with this behavior of the UA is correct?

The behavior of the UA is *correct* relative to the standards, because
the standards only describe what the UA must send over the Internet.

But the behavior of the UA is *not useful* for your application.

The behavior is also *not common* for a UA.  Usually, a UA will render
to the user any RTP that it receives once the UA has sent an INVITE.

My recommendation is to request that the vendor of the UA improve the
UA, or to use a different UA.

> Other thing I am try to looking  for is that UA is failing with one
> way audio too is with the following scenarios.

> According with him, this could be related cause the GW is sending a
> 180WITHOUT SDP, that indicate that GW should not send early media or
> RBT, cause UA should play local ring back tone correct?, but RTP are
> coming from the GW cause I think PSTN is sending RBT.

The SDP in the INVITE tells the UAS(s) how to transmit RTP to the UAC.
Thus, the UAC does not need to receive SDP from the UAS in order to be
able to decode RTP sent by the UAS.

Again, the UAC is *permitted* to discard RTP that it receives, including
RTP that it receives before receiving SDP from the UAS.  But that
behavior is *not useful*.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] [sipcore] SIP-URI Without Userinfo

[Dale R. Worley]

To amplify Christer's replyP:

Christer Holmberg  writes:
>>I have couple of questions
>>
>>1) If I am receiving a sip request without userinfo part in the
>>sip-usri, starting with "@" then is it a malformed packet?
>
> It's a malformed SIP URI.

In particular, it is syntactically incorrect, which you can see by
comparison with the ABNF in RFC 3261 section 25.1 production "SIP-URI".

>
>>2) What should be the standard behavior of SIP server while responding
>>to such packets?
>
> Send a response with an error response code.

Specifically, a 400 response:

   21.4.1 400 Bad Request

   The request could not be understood due to malformed syntax.  The
   Reason-Phrase SHOULD identify the syntax problem in more detail, for
   example, "Missing Call-ID header field".

However, there is a certain amount of freedom that SIP servers have
regarding precisely what 4xx response codes they give for particular
requests, because the errors in SIP requests cannot be precisely
categorized.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Semantics of parameters in URI username

[Dale R. Worley]

Alex Balashov  writes:
> As far as I can tell from the RFC 3261 ABNF, it is permitted to put SEMI 
> and EQUAL in the username of a URI, but it has no semantic validity. 
> That is to say, this is permitted:
>
> 

True, though you probably meant

 

> but doesn't mean anything. 'myval=abc;user' is just one big long username:

That is true.  But since the proxies in a domain are permitted to
interpret the username part however they wish, what that statement means
is that redirection services are not required by 3261 to ignore
"username parameters" that they do not understand.  Perhaps there is
another, less universally implemented standard that specifies this
behavior.

But most telephone carrier networks are closed systems, and whoever is
creating a URI within that domain probably knows whether the domain's
redirection services apply this rule to "username parameters" or not.

Beware that there is a *URI* parameter whose name is "user", and the
text in RFC 3261 section 19.1 refers to it as the "user parameter", so
you have to be careful not to confuse "username parameter" with "user
parameter".

> And yet, there are some specs out there which put tokens which are 
> semantically key=value parameters in the user part of a URI, and expect 
> equipment to extract their values. One spec in particular that comes to 
> mind is RFC 4694 ("Number Portability Parameters for the "tel" URI"), 
> which explicitly contemplates outcomes like this:
>
> Contact: 

Certainly the process described in section RFC 3261 19.1.6 suggests that
equipment will interpret username parameters as you have described.  But
it doesn't require any particular interpretation.

> The ultimate reason for asking is that I am looking to embed a parameter 
> like this in a Diversion URI. I am dealing with a gateway that will try 
> a redirect destination

As far as I know, this depends on the gateway.  What are its
specifications?  Though RFC 3966 defines that the set of tel parameters
is extensible, suggesting that equipment ignores parameters that it does
not understand.  Given the mapping in 19.1.6, that suggests that the
unknown username-parameters in user-parts of derived SIP URIs should be
ignored.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] DTMF digits dupplicate issue

[Dale R. Worley]

Kapila  writes:
> Is it allowed to transmit dtmf in inband audio as well as in dynamic
> payload type ?

As far as I know, it is valid to send DTMF in-band as well as
telephone-events events.  Of course, the two should match, and the
recipient should trust the telephone-events and discard the in-band
DTMF.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Building route set from provisional responses

[Dale R. Worley]

Gagandeep Singh  writes:
> Considering below scenario. (Please view in fixed-width font)
>
> UAC  B2BUA1 B2BUA2 UAS
> |--INVITE->|  |  |
> |  |--INVITE->|  |
> |  |  |--INVITE->|
> |  |  |  |
> |  |  |<---180---|
> |  |<---180---|  |
> |<---180---|  |  |
> |  |  |  |
> |<---183(100rel)---|  |  |
> |  |  |  |
> |--PRACK-->|  |  |
> |  |(-PRACK?>)|  |
> |  |  |  |
>
> (1) Route set due to 180: , 
> (2) Route set due to 183: 
>
> PRACK should be routed as per (2), which will not be possible if route set
> (1) is used.

As all the responders have indicated, within a dialog, the UAS MUST
provide the same Record-Routes for all the provisional responses, which is
indeed the set of Record-Routes that was attached to the INVITE when it
received it.

When B2BUAs are operating, there are two methods of operation:

(1) operate the incoming and outgoing dialogs as specified in RFC 3261,
that is, be a UAC connected to a UAS, or

(2) act as a "quasi-proxy", which does not fully terminate either the
incoming or outgoing dialog, but also modifies the messages within the
dialog in ways that are not permitted by RFC 3261.

In the latter case, the B2BUA has to ensure that the message flow
appears to the upstream and downstream devices to be operating according
to RFC 3261.  (That is not easy to do.)

In the example you diagram, if B2BUA1 is operating in mode (1), then the
PRACK terminates at B2BUA1; B2BUA1 sends a 200 response for it.  But
also, the 180 and the 183 going to UAC do not contain Record-Route
headers for B2BUA2 or UAS; B2BUA1 is the UAS for the dialog with UAC.
B2BUA1 MUST NOT send a PRACK to B2BUA2 because B2BUA1 has not received a
100rel provisional response from B2BUA2.

If B2BUA1 is operating in mode (2), it still MUST NOT send a PRACK to
B2BUA2.  Since it decided to send the 183 itself, it knows that it MUST
provide the response to the PRACK it receives for the 183 -- despite
that it MUST have provided the 183 with the same Record-Route headers
that were on the 180 going to UAC.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Canceling an INVITE still under processing

[Dale R. Worley]

Bogdan-Andrei Iancu  writes:
> Yes, the CANCEL is received before sending the INVITE to the UAS.
>
> Technically speaking (as coding), we can do both - handle the canceling 
> process in the proxy (200 OK to CANCEL and 487 to INVITE, without 
> sending anything further to UAS) , or to delay the CANCEL until the 
> INVITE is send out (and send the CANCEL out to UAS too).
>
> My question is more from the perspective of the SIP standard and best 
> practice for SIP.

Either behavior conforms to the standards.  But it is surely better
practice to terminate the processing of the INVITE in the proxy before
the proxy sends any downstream INVITE.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Video Codec presentation in SDP-Offer/Answer

[Dale R. Worley]

Sachin Rastogi  writes:
> I have a User Agent, which can decode H.264-HP as well as H.264-BP. But it
> can encode only H.264 BP. So how should I share my offer in SDP

Clearly, you can only express this in SDP by providing two different
m-lines, one for the send codec and one for the receive codecs.  (Which
you could bundle.)  The problem that I see is that very few devices will
be prepared to split sending and receiving of a video channel on
different m-lines, they will be looking for one sendrecv m-line that
they find acceptable.

You might have one sendrecv m-line for H.264-BP and a separate recvonly
m-line for H.264-HP.  That maximizes the chance that the far-end UA will
accept the SDP, but only my making it easy to use H.264-BP.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Arbitrary Via parameters

[Dale R. Worley]

Paul Kyzivat  writes:
> Maybe it would. But I think it is more than simply *my* interpretation.

I wasn't aware that there was such a specification.  But I'm sure the
horse is long since out of the barn in regard to un-registered
parameters.  (I once ran a script over a mailbox and discovered 900+
distinct "X-" headers in the messages!)

The big problem is if people invent parameters, minimizing name
collisions.  In this case, the choice "i" is pessimal, because it would
be so easy for others to make the same choice.  Infinitely better would
be something like "x-evaristesys-magic".  Generally, we expect a Via
header to be processed for understanding only by the device that
generated it, but it's wise not to assume that.

Roman Shpount  writes:
> On Fri, Sep 30, 2016 at 5:38 PM, Alex Balashov 
> wrote:
>> That might conflict with the requirement that the branch parameter be a
>> GUID.
>
> Via branch parameter is  the transaction identifying parameter. Its format
> and contents are implementation specific. There is no requirement for Via
> branch (or SIP Call-ID for that matter) to be a GUID. All that is required
> is that these parameters were unique.

I think that Alex is using GUID to mean "globally unique identifier"
rather than the specific form of globally unique identifier called
"GUID".

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] No RBT Fixed IMS CPE's

[Dale R. Worley]

Correcting and updating this, partly based on Paul's message:

wor...@ariadne.com (Dale R. Worley) writes:
> I would suggest adjusting the VoLTE UE's to not send SDP (establish a
> session) until they are prepared to send media, either ring-back tone or
> user media.  Otherwise the CPE has to test the provided media to see if
> it is silent.

I forgot to note that a UAC (caller) or a switch acting on its behalf
should only start to generate ringback to the user when it receives a
180 response.  Other 1xx's don't indicate that ringing has started.
Although if it receives a 181 or 182, it might be useful to provide the
user with a short tone to indicate forwarding or queueing.

Certainly, if SDP is received in a 180, but the device doesn't receive
any media packets described by the SDP, then the device should generate
its own ringback tone.  If the device does receive media packets, the
ideal action is to check whether the media contains silence.  If the
media is silent, the device should generate ringback, and if it is not
silent, it should render the media.  But checking for silence may be too
much work in practice.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] No RBT Fixed IMS CPE's

[Dale R. Worley]

Tarun Gupta  writes:
> It has been observed whilst testing our WiFi/VoLTE solution that when
> a Fixed IMS service (such as Broadband voice or SIP Trunking) CPE
> calls one of our WiFi/VoLTE subs, they do not hear any ring back tone
> as call setup progresses. It transpires that this is because our VoLTE
> UE's always reliably send an SDP in the 183 Session Progress which
> means that the Fixed IMS service CPE's sit there waiting for the
> remote endpoint to provide early media ring back tone which of course
> will never come from the VoLTE UE's.
>
> Has anyone experienced this in their deployments and if yes, what
> solutions were put in place to fix this? (for example network provided
> RBT? removing preconditions?)

I would suggest adjusting the VoLTE UE's to not send SDP (establish a
session) until they are prepared to send media, either ring-back tone or
user media.  Otherwise the CPE has to test the provided media to see if
it is silent.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

[Dale R. Worley]

Paul Kyzivat  writes:
> There is no *general* requirement that there be only one 
> transaction at a time within a dialog, and in fact there are many cases 
> where there are more.

Indeed, it is well-known that having multiple transactions in progress
at the same time is value (though uncommon) -- except if there is a
specific requirement that forbids a particular usage.

It seems to me that the proper way to handle this is to ask the maker of
the SBC for the reference that shows that your usage is incorrect.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Multimedia messaging using MESSAGE method (SIP SIMPLE)

[Dale R. Worley]

Paul Kyzivat  writes:
> Note that you shouldn't be using page mode (MESSAGE) for IM *sessions*. 
> It is really intended for occasional messages. If you are establishing a 
> dialog (via INVITE) specifically for text messaging then you are abusing 
> the mechanism.
>
> For IM *sessions* (text as well as multimedia) you should use MSRP.

Ah, yes.  You can set up an MSRP session using SDP carried in an INVITE.
The MSRP session can carry text as well as other media.  Which I think
is what the preceding answers to your question really mean.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

[Dale R. Worley]

When looking at a race condition, it is always worth looking at RFC 5407
("Example Call Flows of Race Conditions in SIP", often abbreviated to
"Race Conditions in SIP" or even "Hasebe" in honor of the author).  That
is the best collection of carefully analyzed race conditions.

I've added to your example notation of the offers and answers, because
offer/answer processing often controls what is valud and what is not.

"Harrison, Jason, Vodafone UK"  writes:
> Hi,
>
> I have an issue and I can't identify if the behaviour is wrong:
>
> Here is a working call
> Provider   Customer
> SBCSBC
> INVITE (SDP offer 1)-->
> <--100 Trying
> <--180 Ringing (SDP answer 1)
> PRACK -->
> <-- 200OK (PRACK)
> <-- UPDATE (SDP offer 2)
> 200OK UPDATE (SDP answer 2) -->
> <--200OK (INVITE) (SDP answer 1)
> ACK -->
>
> And here is a failed call
> Provider   Customer
> SBCSBC
> INVITE (SDP offer 1) -->
> <--100 Trying
> <--180 Ringing (SDP answer 1)
> PRACK -->
> <-- 200OK (PRACK)
> <-- UPDATE (SDP offer 2)
> <--200OK (INVITE) (SDP answer 1)
> 200OK (UPDATE) (SDP answer 2) -->
> ACK -->
> BYE -->
> <--200OK (BYE)
>
> In the failed call I am being told by the provider that their SBC sent
> a BYE because the 200OK for the INVITE was received before it managed
> to send the 200OK for the UPDATE, I have checked the RFCs and can't
> find if the customer SBC is breaking any rules by sending an 200OK for
> the INVITE before it received a response for the UPDATE

This reasoning seems to be rediculous.  The Provider terminates the call
because it receives one message before it has been able to process the
previous message that it received?  The only way for the Customer to
avoid that would be to send messages in lockstep, only sending one
message after the response to the previous message had been received.

And for that matter, it is easy for the Provider to handle multiple
incoming messages -- just postpone processing the new message until the
previous message has been processed.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] New Invite with same call id received when Non-Invite server is in completed state

[Dale R. Worley]

Brett Tate  writes:
> In my opinion if the device doesn't want to support it, it can reject the
> request (although there might be a better failure response).  However,
> there might be interoperability reasons to support it.
>
> In my opinion, you are experiencing a non-compliant reuse of Call-ID;
> however some vendors have interpreted RFC 3261 differently.  It has been
> many years since I've seen the topic debated; thus I'm not sure if anyone
> or sipcore is currently defending such Call-ID reuse as compliant.

I agree with this -- A device MUST NOT originate a call with a Call-ID
that has ever been used before, therefore a UAS may reject an INVITE
that attempts to create a dialog using a Call-ID that has been used for
a previous dialog, as a reasonable way to cope with the error condition.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] backoff algorithms to prevent registration storms?

[Dale R. Worley]

Paul Kyzivat  writes:
> Strategies for preventing registration storms (e.g., after a major power 
> outage and recovery) have been discussed from time to time.
>
> Can anyone point me to specific documentation of such schemes? Ideally a 
> spec that can be referenced, but failing that I'll be happy with 
> pointers to thorough email discussions or non-standard implementations.

There is draft-shen-sipping-avalanche-restart-overload, but I don't know
to what degree that mechanism was ever implemented.

Pjsip had randomization of its reregistration interval.  See
https://trac.pjsip.org/repos/ticket/1802

In the sipX open-source system, we had the registrar hand out randomized
registration intervals because otherwise, load-dependent delays in
registrar processing would cause all of the phones in the system to
gradually converge to reregistering in synchrony.

But I can't find much discussion of the topic anywhere.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sip-implementors Digest, Vol 29, Issue 16

[Dale R. Worley]

Surya  writes:
> Please let me know what should be the exact call flow when user select
> Airplane mode ON when calling to other name.

Heh!  It's pretty simple:

  UA
   |
   |
   |
   |
   |
   |
   |
   |
   |
   |
   |
   |

I.e., with airplane mode on, there are no messages, either in or out!

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Non-dialog NOTIFY for a SUBSCRIPTION with "Event: presence"

[Dale R. Worley]

pratik patel  writes:
> Is it possible to send Non-dialog NOTIFY for SUBSCRIPTION request with 
> "Event:presence"?

It is possible to send anything.  It may not be useful to do so.

> Will SIP client(3001) accept the NOTIFY request with different call-id
> and cseq [from the SUBSCRIBE which the client used to establish the
> subscription]?

No, the client MUST reject the NOTIFY with a 481 response.  See RFC
6665, section 4.1.3:

   4.1.3.  Receiving and Processing State Information

   Upon receiving a NOTIFY request, the subscriber should check that it
   matches at least one of its outstanding subscriptions; if not, it
   MUST return a 481 (Subscription does not exist) response unless
   another 400- or 500-class response is more appropriate.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] [SIPForum-discussion] SIP to SS7 Calling Number Information

[Dale R. Worley]

Zuñiga, Guillermo  writes:
> I would like to know where I can find information where is defined how
> a C4 define the Calling Number Address information in a IAM, based on
> the information come in a INVITE,

> What use a C4 when the INVITE have a FROM and a RPid Remote Party Id.,

What is a C4?

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SDP header

[Dale R. Worley]

Salil  writes:
> Just wanted to understand that in which all cases/scenario we will see SDP
> information/header  i.e. during  Request/Response session.

Section 13.2.1 of RFC 3261 gives a good introduction to when SDP is sent
in SIP messages.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handoff

[Dale R. Worley]

"Olle E. Johansson"  writes:
>>   Requests forwarded between different types of transports where the
>>   proxy's TU must take an active role in ensuring reliable delivery on
>>   one of the transports MUST be forwarded transaction statefully.
>> 
>> That is, a stateless proxy is not allowed to send via UDP a request it
>> received via TCP.
>
> I am not sure that "transaction statefully" means "on connection-oriented
> transport". It means that it can not be stateless.
>
> Or?

Perhaps I don't understand you, but I think that where I wrote "a
stateless proxy is not allowed to" takes care of that.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handoff

[Dale R. Worley]

"Olle E. Johansson"  writes:
> THis sounds like a cool test-case for SIPit. [...]

> We do have multiple wifi networks with different properties - bad
> hotel network, IPv6 only, dual stack, "normal" wifi (whatever that is)
> - that will stress test implementations.

If there are any significant number of implementations, it would be
great exercise in SIPit.  And I believe that you can buy a WiFi base
station that can configurably degrade the service it provides.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handoff

[Dale R. Worley]

Volkan Hatem  writes:
> Cellular radio-access-type changes are even more challenging: 3G to 4G
> (vice versa) in theory should be nearly seamless. [...]

> 2G to 3G (vice versa) is even more difficult as in many cases the radio
> access will be totally lost causing even longer down time.

Is that because the radio has to be changed from "2G mode" to "3G mode"?
But there is no substantial change between 3G and 4G transmission?

> But in reality IP connectivity will be lost for seconds before it is
> recovered.

When you say "lost for seconds", roughly how many seconds?  Is it 2, or
5, ... or 20?

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handoff

[Dale R. Worley]

Brett Tate  writes:
> If it matters, solutions using things like Replaces and REFER raise the
> typical concerns with authorization, security, billing, et cetera.  For
> instance, see security section of RFC 3891.

Security is "interesting" because there is no guarantee that the new
dialog is handled (at the near end) by the same carrier as the old
dialog.  So whatever authentication technique is used, it has to be
"global".

It also means that the remote target address that the UA sees must be
globally accessible.

If we were willing to bill the two dialogs as separate calls, then
billing would likely be very simple.  But if we want to allow the
possibility that the two dialogs would be billed as one call, the
INVITE-Replaces needs to carry enough information that the carrier can
make that determination.  But perhaps the dialog identifiers in Replaces
are enough, as they do uniquely connect the new dialog with the old one.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handoff

[Dale R. Worley]

Paul Kyzivat  writes:
> ISTM that there is dubious likelihood of success of this is attempted 
> after the previous connection has already failed. Make-before-break is 
> safer if you can get some advanced warning. But make-before-break has 
> its own implications on how you do this so that it doesn't become 
> break-while-trying-to-make.

At least in theory, you can make-after-break, since INVITE-Replaces can
snatch a call from an endpoint that is no longer reachable.  (The remote
endpoint resends BYE many times, and then drops the dialog, but the
user interface is moved to the new dialog immediately.)

As someone else noted, the important thing is to detect the break
quickly enough that the call can be reestablished before session timers
expire.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handoff

[Dale R. Worley]

Volkan Hatem  writes:
> Indeed, INVITE-with-Replaces was the first alternative I could think of as
> well.

> Of course, there are other issues to tackle as well such as
> - NAT traversal, whether ICE or a simpler (always insert a proxy when NAT
> detected) mechanisms can be preferred.
> - The time it takes to get an IP connectivity, resolve proxy addresses
> might complicate it if it takes too long

Yes, there is definitely going to be some delay apparent to the user,
unless the UA can get warning and use a make-before-break technique.

Other than delay, an INVITE-with-Replaces can use the same techniques
the original INVITE used for dealing with NATs, etc.

> - Whether it conflicts with other operations requiring re-INVITEs as well
> (updating session description to add/remove/modify media)

One necessity is that an INVITE-with-Replaces needs to be processed with
the same sort of glare logic that a re-INVITE does.  Otherwise, if both
endpoints attempt INVITE-with-Replaces simultaneously, the call is
likely to fail.

Similar considerations probably apply to UPDATE.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Handoff

[Dale R. Worley]

Roman Shpount  writes:
> We actually always use UDP like re-transmits even when sending SIP messages
> over TCP or TLS. There are enough implementations that connect TCP or TLS
> interface with UDP using a stateless proxy which make it necessary.

Just last night, I found this requirement, which I had long forgotten:

RFC 3261, section 16.1

   Requests forwarded between different types of transports where the
   proxy's TU must take an active role in ensuring reliable delivery on
   one of the transports MUST be forwarded transaction statefully.

That is, a stateless proxy is not allowed to send via UDP a request it
received via TCP.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Handoff

[Dale R. Worley]

Is there any generalized technique for "handoff", for moving a SIP
dialog from one interface/medium to another?

My impression is that this problem is most commonly seen switching
between a mobile connection and a WiFi connection, but it can happen in
pure-SIP situations as well.

So far, it seems that a UA could use INVITE-with-Replaces (sent from the
new interface to the other party) to transfer the dialog from its old
interface to its new interface.  Has anyone implemented such a
technique?

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Are 'alert' URNs being used?

[Dale R. Worley]

Does anyone know of implementations of the 'alert' URNs in Alert-Info
(RFC 7462) beyond the use of urn:alert:service:call-waiting by 3GPP?

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Media and Signaling IP

[Dale R. Worley]

Rakesh  writes:
> Could you kindly please let me know is there any standard which says that
> the media and signaling IP should be diffrent in SIP INVITE ..

No, the media and signaling IP addresses can be the same or different.
Also, the media address(es) can change during the dialog if a new SDP
offer/answer is negotiated.  The signaling IP address can *also*
change -- the dialog that a SIP request is part of is determined by the
Call-Id header, the to-tag, and the from-tag, not the address from which
it originates.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] UNKNOWN Transport type specified in VIA header

[Dale R. Worley]

Brett Tate  writes:
>> If UAS receives a SIP message (over UDP/TCP in our
>> case) from peer and in this case there is only one
>> VIA header present and transport type of this VIA
>> header in UNKNOWN (Here, UNKNOWN transport type means
>> either we are not supporting this transport or the
>> transport specified in VIA header is INVALID). Now,
>> what should be the behavior of UAS? Will UAS rejects
>> this message with 400 "inconsistent transport" or
>> call gets successful over transport on which request
>> is received (TCP/UDP).
>
> Since the sender is non-compliant, the UAS can basically act however it
> wants.

Worse, since the UAS can't understand the transport type, there is no
defined way for it to send an error response to the UAC.  I suppose it
could guess what the transport type should be, based on how the message
was received, but RFC 3261 doesn't require that.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors