[Sip-implementors] quoting in RFC2617
Hi,
RFC2617 defines the following rule to extract header values for
calculating response:
===
The notation unq(X) means the value of the quoted-string X without the
surrounding quotes.
===
and later e.g.:
===
request-digest = <"> < KD ( H(A1), unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
===
If we have e.g.
Authorization: realm="a\"b", nonce="1234", ...
what text value should be literally applied here?
V1) a"b (in hex: 61 22 62)
or
V2) a\"b (in hex: 61 7c 22 62)
?
Common sense requires first one, but exact definition ("value without
surrounding quotes") gives argument to second one. Moreover, there is
strange requirement of RFC5090:
===
Quote and backslash characters in Digest-* attributes representing
HTTP-style directives with a quoted-string syntax are escaped. The
surrounding quotes are removed. They are syntactical delimiters that
are redundant in RADIUS. For example, the directive
realm="the \"example\" value"
is represented as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest-Realm | 23 | the \"example\" value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
===
If correct is (V1) (see above), this requirement is quite weird
because if h_Authorization is already parsed, it's reasonable to keep
its values in canonic internal form, so to form RADIUS request NAS
shall re-quote values, or add ugly getters for externally represented
values.
Could anybody please give URL to discussion on this, what
interpretation is correct and why so strange mechanisms are used?
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:ne...@portaone.com
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is this TEL URI global or local?
>>>>> I??aki Baz Castillo wrote: > Hi, imagine the following TEL URI: > tel:(+34)-999-888-777;phone-context=foo.com One shall not generate such URI because parentheses aren't allowed there; as soon as they are human-specific syntax sugar, it's better to remove them on generation. But, if you want to accept such URL from bad generator - hmmm, whynot... And, I have known preferred form for such numbers is e.g. +(34)999-888-777 but not as in your example... -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:ne...@portaone.com ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] False security in RFC 3261 "17.2.3 Matching Requests to Server Transactions"
Hi, >>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: >> This have some sense (but we shall say again - not in security >> context). Imagine two different NATs and two agents behind them, >> both on address 192.168.1.1, and with monotonic branch numeration >> (z9hG4bK1, z9hG4bK2, z9hG4bK3...) If rule is "compare sent-by", >> their branches will mix. > It expected that branch value is so random and big that it can't be > repeated, isn't? It's recommended, as the simplest path to satisfy the requirement, but the real requirement is simply === cut here === The branch parameter value MUST be unique across space and time for all requests sent by the UA. === end cut === so we can imagine e.g. stable storage (NVRAM) of mototonically increased number of 64 bits:) > However I think we can expect that there will be > never two identical branch values coming from same public IP at the > same time. One public IP of NAT is good case to have pool of identical UAs. >> Correct matching shall take all four >> known identifiers (sent-by.host, sent-by.port, received, rport), >> and I'm unsure it was really correct to drop all another >> identifiers from matching (according to RFC2543); >> as minimum, we >> can add call-id, from_tag and CSeq number to matching, because >> none other rule allows to change them inside transaction. > Sure, but wouldn't make it too much "expensive"? Yes, for some applications, as fast proxy, it can be too expensive. But such application still needs some way to calculate branch uniquely. We have got problem with SER 0.9 which calculates branch as hash of raw text of some header fields, and if UA sends to_tag of provisional response in CANCEL (this is very common error), or makes some other change in header (one case was - UA which prepends in h_From with space in INVITE but doesn't this in CANCEL) SER makes another branch ID when resends such CANCEL and we are unable to match it to INVITE. For such cases, I expect matching in RFC2543 style is more working.:) I don't know whether is this fixed in modern SER. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] False security in RFC 3261 "17.2.3 Matching Requests to Server Transactions"
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > The request matches a transaction if: > 1. the branch parameter in the request is equal to the one in the > top Via header field of the request that created the > transaction, and > 2. the sent-by value in the top Via of the request is equal to the > one in the request that created the transaction, and > The "security" offered by point 2 (matching the sent-by) is really > inefficient. I understand you, but please don't name it "security". Transaction matching rules don't give real security, they protect against non-intentional collisions. > So, don't you think that point 2 of 17.2.3 should just dissapear since > it just offers false security? Instead of this I'd prefer to read > something as: > 2. the source address of the request is equal to the source > address of the > request that created the transaction. This have some sense (but we shall say again - not in security context). Imagine two different NATs and two agents behind them, both on address 192.168.1.1, and with monotonic branch numeration (z9hG4bK1, z9hG4bK2, z9hG4bK3...) If rule is "compare sent-by", their branches will mix. Correct matching shall take all four known identifiers (sent-by.host, sent-by.port, received, rport), and I'm unsure it was really correct to drop all another identifiers from matching (according to RFC2543); as minimum, we can add call-id, from_tag and CSeq number to matching, because none other rule allows to change them inside transaction. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP end points behind firewall/NAT registering to public IP registrars/sip servers
>>>>> Dushyant Godse <[EMAIL PROTECTED]> wrote: > I am trying to analyze deployment of a B2BUA NAT equipment to be > deployed as part of a solution. My SIP end point are deployed (as in > home agents) deployed behind a NAT/firewall and sends messages across > the B2BUA NAT device to SIP Servers/registrars located in the public > network. Are there known limitations to the kind of sip end points that > be used? Should sip end points specifically support symmetric RTP and > SIP? Symmetric SIP and RTP (i.e. announce the same address (host:port) which will be source address) is really important for work behind NAT because allows simple detection of external address directly from recvfrom() :) Otherwise both sides shall implement STUN (not working for all cases), ICE (cumbersome) or similar horrible approach. But if your "B2BUA NAT device" (what's this???) sits on NAT border and proxies RTP, none of this is really needed. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query regarding sending of symbol #
>>>>> Paul Kyzivat <[EMAIL PROTECTED]> wrote: > I have to disagree with the point here. > Some might describe me as a "grammatist", in that I prefer a formal > definition of the grammar to an informal one. > The issue isn't that the syntax is formally specified by a grammar. It is > what syntax was chosen to be formalized. It would be equally grammatical to > choose a simpler form. No. I meant approach to exploit a grammar to obtain maximal flexibility (but making parsing and changing more complex) instead of more restrictive, but easier to deal with, approach. > There clearly are conflicting goals in choosing the syntax for a protocol > like sip. I wasn't there when it started, so I won't speak to exactly what > the motivations were for the choices made then. Clearly there was a > decision to model it after email. That's why I mentioned RFC822. But one shall still give credit for avoiding most horrible approaches, as its quoted-string. Current SIP grammar allows either grammatical and regexp-supported parsing, as opposed to email one. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query regarding sending of symbol #
>>>>> IЯaki Baz Castillo <[EMAIL PROTECTED]> wrote: > Anyway, if SIP wouldn't be SO permissive, if it would be more > restrictive, > implementations would be easier, more effective and with better performance. > But no, instead of that let's allow any kind of symbols, escaping, ridiculous > URI headers, painful URI comparissions that NOBODY implements (19.1.4), etc > etc... This is common IETF problem: it's occupied by grammatists with paranoia of permissive approach. Another example is case-insensitive matching in text protocols, which requires to spend memory for copy of any header, field or attribute name which is written in non-canonic form (e.g. "Call-ID" vs. "call-id"), field name aliases, etc. The greatest example of grammatists' defeat was RFC822 which had got NONE fully correct implementation among widespreaded ones. But this didn't give them any experience. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Query regarding sending of symbol #
>>>>> Koshy Thomas <[EMAIL PROTECTED]> wrote: >I have query regarding sending of symbol # in a SIP INVITE message > Request-Line. > Should it be send as %23? Does any RFC mention so? Yes, it MUST be sent as %23. But "in practice, theory and practice differs". We are constantly obscuring problems with Cisco, Quintum and some other vendors' hardware which doesn't accept '%23' on input. I can't tell whether is it device software problem or setup problem, but this is so often that we had to invent special options in softswitch to specify hosts that require "#" instead of "%23" in incoming (to them) INVITEs. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is "Contact" header required in101-199 responses?
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: >> I propose another interpretation. As soon as Contact is supposed >> to change remote target of message receiver, and as soon as there >> is some initially assigned remote target when INVITE is set > Could you explain what you mean with "and as soon as there is some > initially assigned remote target when INVITE is set"? > How can be the remote target assigned just when sending the INVITE??? Dialog data in UA contains remote target. (See section 12 for details.) RFC3261 doesn't declare (AFAIK) its initial value, but it declares - remote target shall be set to contact value of response - remote target shall be used for RURI of next requests within dialog (except case of strict routing - but this is corner case) It doesn't limit implementation, but the only implementation which conforms common sense is that when UA (as UAC) sends initial INVITE, remote target in the UA state is already assigned to the value sent in RURI. Having the remote target unassigned until first response with contact is IMO senseless - particularly, because there is no strong rule to carry contact in each response. >> For finishing of early dialog, I suppose you should extract contact if it is >> sent in response, and avoid to change remote target otherwise. > I really can't understand it. The "remote" target is the received > "Contact", so if there is not received "Contact" during 1XX responses, > then there is no remote target and in-dialog requests are not possible > from UAC to UAS. Am I wrong? See above. To clarify: this is kind of proof "by the rule of contraries": supposing that the remote target is initially unassigned you fall in contradiction with section 20. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Any RFC documenting a B2BUA?
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: >>> - Can be problems if B2BUA copies in leg 2 the same "Call-Id" and >>> "From_tag"? >> Yes, it's roughly incorrect. It can copy call-id, but MUST create >> new tag, because it creates new dialog. If it were keep dialog >> unchanged, it would be named "proxy", not "B2BUA". > Well, even if two B2BUA legs (two independent but connected dialog) > share From tag it's still a B2BUA, not a proxy, since the B2BUA can > redirect leg A to other destination (as you said). I understand your position, but there are some another problems with this approach. In real world, you can't predict for all cases whether your outgoing leg will pass the same servers as incoming leg. If you maintain code of border system (e.g. between Internet and local network) and it's improbable that this code will be used for other setup style, you can do this. But in general it's quite danger. I don't suppose you're writing stack for such local task; likely it's universal one. If so, better create new tag and avoid any chance for having identical leg ID. > Thanks a lot for your reply. not at all :) -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is "Contact" header required in101-199 responses?
>>>>> "Rockson Li (zhengyli)" <[EMAIL PROTECTED]> wrote: > Yes, that is my interpretation. Note that a "MUST" in the text of RFC 3261 > takes precedence over the content of Table 2. You can't reject table 2 in so easy way;) Yes, the table itself doesn't have the magic words from RFC2119, but the section contains rules to interpret it. These rules declare "MAY". If there is some another rule which declares "MUST", this is Yet Another Contradiction Example and should be treated accordingly - by creating an official explanation. But you can't declare such precedence only via fact it's table, not text. > If any in-dialog request needs to be sent prior to receipt of the final > response, then the Remote Target (from the Contact) and Route Set (from the > Record-Route) must be set up based on the 1xx response. This is needed > especially if reliable provisional responses are being used. The PRACK needs > the remote target and route set. Some User Agents like to send DTMF in INFO > requests, and like to do it before the session is established. I propose another interpretation. As soon as Contact is supposed to change remote target of message receiver, and as soon as there is some initially assigned remote target when INVITE is set, there is no reason to change it unless it's really changed. That's why it's practically correct to see response without contact. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is "Contact" header required in 101-199 responses?
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > Hi, as Bob Penfield pointed in a previous mail, RFC3261 doesn't > clarify if a 1XX response (that creates an early-dialog) MUST or not > contain a "Contact" header (that would be need, for example, to send a > BYE to terminate the early dialog instead of using a CANCEL). Why do you think so? See table in section 20: Header field where proxy ACK BYE CAN INV OPT REG ___ Contact Ro - - m o o Contact1xx - - - o - - Contact2xx - - - m o o Contact3xx d- o - o o o 'o' in crossing of "1xx" and "INV" means "optional" and this is explained in the section: === "Optional" means that an element MAY include the header field in a request or response, and a UA MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 20.32). === For finishing of early dialog, I suppose you should extract contact if it is sent in response, and avoid to change remote target otherwise. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Any RFC documenting a B2BUA?
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > Hi, the only reference to B2BUA concept I find in RFC 3261 is: There is draft-marjou-sipping-b2bua. But IMHO it's quite restrictive and reflects somebody's specifics without considering the goal in common. > - Is legal for a B2BUA to change completely the "From" in the second leg?: Yes. Really, B2BUA can do *anything* which doesn't break its functioning. That's why there is no standards for it. But usually B2BUA is used for specific processing which isn't directly allowed for proxy. For example, B2BUA in PortaSIP can connect caller to media server which says post-call words when the main call is finished. Proxy can't do it. > - Should a B2BUA allow unknown headers from leg 1 to leg 2? or should > it create a completely new request from scratch? Initially our B2BUA (based on old Vovida's one) used request modification strategy, i.e. any header which isn't directly deleted or changed by B2BUA was passed through. Later we considered this was invalid decision. Currently it passes only those headers which are directly declared as copied by main logic or by config option. > - Can be problems if B2BUA copies in leg 2 the same "Call-Id" and "From_tag"? Yes, it's roughly incorrect. It can copy call-id, but MUST create new tag, because it creates new dialog. If it were keep dialog unchanged, it would be named "proxy", not "B2BUA". -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Digest response with no "qop" even if 401 included it [SOLVED]
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > Well, RFC 3261 says: >22.4 The Digest Authentication Scheme > 8 - ... > However, > servers MUST always send a "qop" parameter in WWW-Authenticate > and Proxy-Authenticate header field values. If a client > receives a "qop" parameter in a challenge header field, it > MUST send the "qop" parameter in any resulting authorization > header field. Note that there are too many proxies that does not send and count qop, so client really shall compute authorization also for variant without qop. For simple but working implementation, it's enough for UAS to generate nonces cryptographically randomly, keep a few last nonces and expire them periodically to protect against any replay attack later than nonce expiration. More complicated implementation shall keep nonce sent to each client separately... this can be too expensive. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] NAT and "18.2.2 Sending Responses"
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > Hi, imagine a request from NAT received by a UAS with publi IP: > # INVITE from 80.80.80.80:5060 > Via: SIP/2.0/UDP sip:192.168.0.100:5060 > The UAS converts t to: > Via: SIP/2.0/UDP sip:192.168.0.100:5060;received=80.80.80.80 > Now imagine the UAS replies a 404 but gets an ICMP error, so it must perform: You touched the very complicated topic - how to deal with client behind NAT. The answer for this particular case is: if you are sure the client is behind NAT - _force_ adding rport to topmost Via even if this Via doesn't contain it (with or without value). > 18.2.2 Sending Responses > o Otherwise (for unreliable unicast transports), if the top Via > has a "received" parameter, the response MUST be sent to the > address in the "received" parameter, using the port indicated > in the "sent-by" value, or using port 5060 if none is specified > explicitly. If this fails, for example, elicits an ICMP "port > unreachable" response, the procedures of Section 5 of [4] > SHOULD be used to determine where to send the response. > So finally it would send the response to IP 192.168.0.100:5060 To 80.80.80.80:5060, if rport isn't added. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Why a nortel CS2K softswitch requires "To" in format "00XXXX" ?
>>>>> Paul Kyzivat <[EMAIL PROTECTED]> wrote: > Right. Lets take an example: > Assume call is initially To: sip:[EMAIL PROTECTED] > Alice forwards it to sip:[EMAIL PROTECTED] by putting that into the R-URI. > (To > URI is unchanged.) > The call then arrives at the softswitch for biloxy.com. The softswitch > then rewrites the R-URI with the contact for Bob's device: > sip:bobphone.biloxy.com. > When the invite reaches the phone, it tries to use the To-uri to figure out > which line the call was addressed to. But it is expecting it to be either > sip:[EMAIL PROTECTED] or sip:[EMAIL PROTECTED] It is not expecting > sip:[EMAIL PROTECTED] and so can't figure out which line was intended. This example shows only that any approach has its limited usage scope and won't work when is used in inappropriate way. And the main point is final UA ignorance of target. If this were, for example, Bob's call center which proceeds secretary service for its subscribers including Alice, it can use any header field to detect what target was original to this request - if it sees Alice in h_To, it would accept calls as targeted to Alice, use Alice's incoming voicemail pool and even greet as "Alice enterprises, please leave your message after beep". But you explicitly denied its intelligence to distinguish calls using h_To, and that's your choice, not its. > Paul -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Why a nortel CS2K softswitch requires "To" in format "00XXXX" ?
>>>>> Paul Kyzivat <[EMAIL PROTECTED]> wrote: >>> Is it ""normal""? Why the hell does a softswitch require *anything* in >>> the "To" URI? (except the To_tag XD). >> Even if you found that this wasn't correctly detected, generally >> it is quite normal to check and use username in h_To as something >> another than username in RURI. It can be used, for example, to >> select specific DID number across the pool assigned to the >> customer specified in RURI (this is used e.g. in Sipura/Linksys >> SPA9000 as one possible form of such DID specification). See also >> ISUP specs and draft-yu-tel-url: they specify special "routing >> number" which also can be passed, in different tradition, in RURI >> (while final number is passed in h_To). > Yes, it isn't unusual to see that done. And it is BROKEN! > That algorithm breaks any time a call is forwarded. What do you mean here for "forwarded"? If forward as proxy according to rules in chapter 16 - proxy doesn't change h_To.url.username. If some another kind of forward (e.g. via B2BUA) its agent is usually aware of this difference. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Why a nortel CS2K softswitch requires "To" in format "00XXXX" ?
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > The worst is that this requeriments doesn't only affect to the RURI but to > the "To" header. So an INVITE like this: > INVITE sip:[EMAIL PROTECTED] SIP/2.0 > To: > Is replied with a "487: Request Terminated" by Nortel (also I'm 100% sure > that > 487 shouldn't be used for this purpose). > Is it ""normal""? Why the hell does a softswitch require *anything* in > the "To" URI? (except the To_tag XD). Even if you found that this wasn't correctly detected, generally it is quite normal to check and use username in h_To as something another than username in RURI. It can be used, for example, to select specific DID number across the pool assigned to the customer specified in RURI (this is used e.g. in Sipura/Linksys SPA9000 as one possible form of such DID specification). See also ISUP specs and draft-yu-tel-url: they specify special "routing number" which also can be passed, in different tradition, in RURI (while final number is passed in h_To). -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Difference between B2BUA and Proxy
>>>>> Vinayak Joshi <[EMAIL PROTECTED]> wrote: > What are the differences between the B2BUA and Proxy? B2BUA can do things that aren't allowed for proxy: e.g. convert media codecs, recombine legs and merge calls (conference, pickup, attended transfer, etc.), mask all caller details and expose call as originated from this B2BUA, generate pre-call, in-call and post-call voice messages (e.g. for allowed time, one-minute notification beeps and remaining costs), and so on. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] quoted URI parameters (especially, tgrp)
Hi, is there a new RFC or even draft which allows syntax like Contact: ? According to RFC3261, quotes aren't allowed for pvalue, but seems style as shown is common at least for two vendors. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] ABNF: token and comment unexpected behaviour (space)
>>>>> [EMAIL PROTECTED] wrote: >From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= <[EMAIL PROTECTED]> > Not wanting to sound cranky, but I find it ironic that in a discussion > about the weirdness of the RFC 3261 grammar, the participants do not > understand to wrap lines at 80 characters, and in many cases, lose the > line-breaks in text that they are quoting. Please, the questions are > difficult enough, don't make the messages themselves unreadable! Dale, 1. I suppose the problem is in KMail, not in sender (ibc@) personal style, manner or tradition, because KMail incorrectly forms base64 encoded entity: RFC requires that text shall be converted to network delimiters (CRLF) before encoding; KMail doesn't do this, and its decoded entities carry only bare LFs. This is well-known KMail bug (at least for five last years) and still unfixed. Different mail agents interpret such entities in different way. My one (Mutt) interprets bare LFs in such entity as line breaks, so I have no problems to read this messages. But many other agents and utilities may fail to restore this correctly. (To In~aki Baz Castillo: would you please use other mailer than KMail? For example, Thunderbird is stably reported as convenient tool. I don't suppose setting 8bit output option would fix this, at least unless utf-8 is strictly supported on the whole path.) 2. I agree with you for particular case;) But in general, _your_ messages is rather unreadable (yes, _IMHO_) because you don't follow any existing quoting norm (line prefix "> " for usual text/plain and its flowed variant, etc.) instead using weird space prefixing; so _for me_ it's much easier to read ibc@ messages than yours (yes, while my Mutt understands spoiled base64). But your messages are still easier to read that of those strange guys which don't use indentation or prefixing at all and mark own words with something like [ABC] ... [/ABC] ([EMAIL PROTECTED] is full of such postings). That's the most terrible case I've seen in SIP lists.;) -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Handling Multiple 183 Response
>>>>> ?? <[EMAIL PROTECTED]> wrote: > I have a question how SIP UA should react when it receives two 183 responses > containing > each different SDP body. As far as I am concerned, only the first 183 > response should be > counted and the subsequent 183 response should be ignored even though it > contains different > SDP body. No, better is to react on each new one with replacing of old one, because there can be multiple gateways on call path when each one generates some new sound (ringback emulation, credit limit notification, vendor greeting, etc.) -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP ABNF: Doubt about params in name_addr/addr_spec
>>>>> Valentin Nechayev <[EMAIL PROTECTED]> wrote: >> a) >> From: sip:[EMAIL PROTECTED];custom_tag=X;tag=x >> b) >> From: NAME ;tag=x >> In a) "custom_tag" and "tag" are URI params, >> while in b) "custom_tag" is an URI param and "tag" is a "from-param". > Yes. Sorry, I misread your example - for (a) both custom_tag and tag are from-params. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP ABNF: Doubt about params in name_addr/addr_spec
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > a) > From: sip:[EMAIL PROTECTED];custom_tag=X;tag=x > b) > From: NAME ;tag=x > In a) "custom_tag" and "tag" are URI params, > while in b) "custom_tag" is an URI param and "tag" is a "from-param". Yes. > I know that both are equivalent since some SIP implementation use a) and > others b), but it seems a bit ambiguous, don't you think so? See paragraph 20: === The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. === Here, grammar is incomplete. Complete grammar should look like following: From= ( "From" / "f" ) HCOLON from-spec from-spec = ( name-addr / addr-spec-short ) *( SEMI from-param ) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI addr-spec-short = SIP-URI-short / SIPS-URI-short / absoluteURI-short SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] SIP-URI-short = "sip:" [ userinfo ] hostport // SIP-URI-short shall NOT contain uri-parameters and/or headers Note the formal definition of SIP-URI-short. I didn't try to fix all issues in this definition, so use it only as common plot. P.S. I'm very glad to see how you dig all these perularities - maybe your implementation will be _the first_ which really conforms all existing specifications without explicit bugs.:)) -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] When does UAC has to re-send REGISTER message?
>>>>> ?? <[EMAIL PROTECTED]> wrote: > As shown in title, my question is when UAC has to re-send REGISTER message to > refresh its binding in REGISTRAR? Let's say that UAC has received 200 OK > meessage whose expire parameter value in Contact header is 3600. I think I > have read somewhere in RFC which says subsequent REGISTER message should(?) > be send at the time when half of the expire value in 200 OK is elapsed. > Unfortunately I don't know exactly where I have read this, and all I find now > is that UAC is supposed to send REGISTER message simply before expire > interval elapses (RFC3261 10.2.4). Isn't there anybody who can clearify this? Before expiration-64*T1, but no earlier than expiration/2. Of course, there is no exact specification, but I try to follow existing traditions and common sense: 1. There is no need to issue re-regisering request earlier; instead, the latest possible moment shall be used. (Otherwise, expiration negotiation was invalid and one should either change server or client setup.) 2. In DHCP (another well-known and mature protocol with client registration), lease request should be issued after 1/2 of lease expiration interval. This doesn't add too much useless load, but allows to deal with temporary network problems. 3. As soon as client should be re-registered before its expiration, client should give enough time for server and network to deal with request. The maximal allowed time for this is 64*T1, according to paragraph 17.1.2 (Non-INVITE Client Transaction). So, request should be issued before expiration-64*T1. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Why SIP abnf is so permissive???
>>>>> IЯaki Baz Castillo <[EMAIL PROTECTED]> wrote: > b) > > Content-Length: > > > 46 > > Both a) and b) are correct, and b) is not more human readable at all. Also a) > is 400 times easier to parse than b) so, why allow b) ? Because IETF is grammatist realm. If something is supposed to use text format, it's allowed to use free form syntax. Your example (b) is too radical, it's better to compare with something like: === c) INVITE sip:[EMAIL PROTECTED] SIP/2.0 From: alice <[EMAIL PROTECTED]>; tag=1 To : white rabbit <[EMAIL PROTECTED]>; tag=2 i : [EMAIL PROTECTED] === which isn't much worse than non-spaced form. Grammatist approach is that if something can be declared as grammar, declare this grammar and then allow any text which allowed by some grammar, without artificial limits. If you e.g. declare that some spacing can't exceed 20 spaces, it's artificial limit. Compare with recommended limit of 1300 bytes per message, which is transport-specific limit. Generally message generators don't add wasting spaces and other curlicues because this increase probability of transport limit overflow. > Ok, I understand that SIP was born from HTTP and so, but anyway I hope in a > future SIP/X.0 appears eliminating so many and innecesary permissive syntax. If to invent such, this already won't be text format, and with avoiding of freeform format one really has to invent binary-like format. Even if this format, unlike real binary format, isn't allowed to carry arbitrary byte values, it has binary format limitations by definition. There were cases of such approach (e.g. FTN message and packet formats) and I can't definitely say this experience is positive. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Why "Content-Length" is just mandatory in TCP? (in UDP if there isn't it assumes 0 bytes)
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > Hi, AFAIK reading RFC 3261, using UDP the header Content-Length is not > mandatory and if it doesn't appear it's considered 0. No, if it doesn't appear it's considered undefined and body length isn't checked. But if it is equal to 0, body is ignored. > But using TCP Content-Length is mandatory. I understand that in TCP the same > connection can handle lost of messages s/lost/lot/, yeah? > while in UDP a message fills exactly one UDP datagram. > Why content length is not set to zero if Content-Length doesn't exist in a > TCP > SIP message? The question is incorrect because your assumption is invalid. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Making a SIP stack: implement all the SIP BNF as RegExp or not?
>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote: > Hi, I've used a BNF_to_RegExp converter to get all the RFC 3261 BNF code as > Ruby RegExp. This could seem nice, but now I'm not sure if I should use these > RegExp or not since they are very very long... For many cases, there is no need to include all grammar for all levels. E.g., to extract URI from header, very relaxed URI grammar can be used, as a character class or small expression with character classes. Later, when parsing URI, you'll use more detailed expression. The same for another complicated elements. I've got negative experience with complicated grammar regexps and NFA regexp engine with exponential growing of matching time (up to a few days for short URI), so changed to use the simplest available form to separate into smaller sentenses and then parse them separately. > Do other SIP stacks use those RegExp? No strict need; seems the main approach is to use parser generator (e.g. yacc), but grammar from RFC shall be tuned. E.g. paragraph 20 which differentiates case of name-addr and addr-spec needs special reflection in grammar. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] CANCEL retransmisson question of no provisional response!
>>>>> Robert Sparks <[EMAIL PROTECTED]> wrote: > Part of why it does this is to deal with the case that the first > INVITE the proxy sent actually got somewhere, but its response was lost. Non-reliable response can be lost even after first 100 and no RFC recommends to retry initial INVITE until final response is got. To obtain provisional responses reliably, PRACK is invented, not retransmission of INVITE. > The retransmission will stimulate a retransmission of the response, The only thing which it really stimulates is useless pinging of vacuum. Of course, CANCEL shall be pending until the final transaction timeout is got (and so, if remote really got our INVITE, resent), but this isn't reason to retry INVITE for cancelled transaction. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Header fields in the B2BUA scenario
>>>>> Stephan Steiner <[EMAIL PROTECTED]> wrote: > I have a SIP PBX which works in B2BUA mode and I've noted that when it comes > to dealing with Header fields, it doesn't stick to the table 2 in chapter > 20.1 of RFC 3261. Specifically, it is modifying some header fields which > according to that table may not be modifed by a proxy. I contacted the > manufacturer and they claim that since a B2BUA isn't a proxy, they don't > have to follow the rules established in the RFC Right. > and I'm having a hard time > countering that since to me, a B2BUA is a proxy seeing as it does what a > proxy does (even if the RFC doesn't spell that out) Wrong. > but I'm wondering: > Is there any type of UAS to which the header processing rules mentioned > before do not apply? Is B2BUA really a loophole to not do things a proxy > should do just because it isn't a real proxy per definition (even though it > basically does the same things.. it just does more than a proxy does)? Yes, it can change RURI, do hunting of multiple destination sequence, rewrite bodies, interrupt a call if it is too long, & so on & so forth. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Querry about INVITE and 100 Trying
>>>>> "Goyal, Amit" <[EMAIL PROTECTED]> wrote: > It should wait for 64*T1 and then terminate the session. No. Such wait is used only before first provisional response. Time for full INVITE transaction is not limited. See transaction state diagram and e.g. paragraph 13.3.1.1. >> What should be the behaviour of UAC in the below >>mentioned scenario >> >> "after sending an INVITE request , it will receive >>100 trying response , after that it will not receive >>any further responses." Such timeout is implementation-defined. There can be reason to wait for any time:), but in real some timeout shall be invented according to usage of this call. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SDP in unreliable 183 and 200
>>>>> Raj Jain <[EMAIL PROTECTED]> wrote: > The SDP in 183 and 200 must be same (including the version number). This is > a known bug in Asterisk. Could you please point to RFC which requires equalness for such two SDPs? -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] 200 Auth Failed ?
>>>>> Robert Sparks <[EMAIL PROTECTED]> wrote: > SIP/2.0 200 Failed > is perfectly legal and means exactly the same thing as > SIP/2.0 200 OK > And as Scott points out below, you really don't want to say 200 when > you don't mean it. '200 Auth failed' is common method to allow human hearable error message on real call with UAs which can't detailedly describe error (most often for ATAs). UAs will think it's registered and allow outgoing call, which will be rejected with voice description. This is likely the main need to use such crutch but this is strong needed crutch. >> That having been said, it can be a problem for the server when phones >> just keep retrying (and some do the retries obnoxiously fast) after >> failures, so switching to a different status can be done to get the >> phone to stop. A 200 response would be a very poor choice for this >> (although it would stop the retries) because it make diagnosing the >> system problem very difficult. No, it isn't if voice notification on INVITE works well. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] support for payphone-style delayed start
Hi, we have idea to implement a feature when on initially established call, caller's voice stream isn't relayed to callee until caller sends special notification to proxy that he hears initial greeting from callee. This is transition of well-known old style for street payphones in some cities, where a button was designed to be pressed by caller when he hears greeting (and no coins were absorbed before this). Two questions appeared during developing this: 1. How caller shall notify intermediate proxy (or B2BUA) about the moment caller really confirmed the call? I anyway can use fallback to in-dialog INFO, but it was noted here many times that INFO is bad because overloaded with very different usings. 2. The B2BUA shall proxy RTP traffic; due to used NAT traversal style it shall be passed to callee even during initial silence from caller. I suppose to send "empty" RTP packets without payload. What drawback can appear in this case? -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] REG updation by SIP_Client or SIP-server ?
>>>>> Tapan Kumar Biswal <[EMAIL PROTECTED]> wrote: >My SIP Client seding the REG request witout Expire time and Contact > Header but when it is getting 200 OK from the Server , The Server is > automatically assign Expire=1800 to the SIP-client . > But the problem is It is not geeting anymore Incoming call after > 1800 sec. Unless untill i reboot my SIP-client. Is the client behind NAT? > SO i wanna to know Is it mandatory that the SIP-client should Update its REG > with Server or Server it automaticall update for the SIP-client ? Client shall update registration before its expiration. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
>>>>> Stefan Sayer <[EMAIL PROTECTED]> wrote: >> complete treatment, see >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt > where you write in 4.2.5. Subsequent Offers and Answers: > o In the o-line, only the version number may change, and if it > changes it must increment by one from the one previously sent as > an offer or answer. If it doesn't change then the entire SDP body > must be identical to what was previously sent as an offer or > answer. This is the most often misimplemented part. It's usual to see UAs which send e.g. SDP with session ID and version both identical and showed a time from session start, either for the same SDP or changed one; or in another broken mode. In practice, one shall never rely on this (in 4.2.5) rule. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Question Regarding NAT Query
Tue, Jul 10, 2007 at 17:31:03, santosh.yadawad wrote about "[Sip-implementors] Question Regarding NAT Query": >When UA sends INVITE message it will query the NAT and will > get the public ip-address from its private ip-address. > So what will be the contact header field in INVITE Message > weather its public ip (obtained from NAT) or it's a private (local ip). It seems the best reply is URL to fresh document about it: http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.txt -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] sip vs h323
Fri, Jul 06, 2007 at 09:53:37, artunmurat wrote about "[Sip-implementors] sip vs h323": > Take a look at below comparison? > http://www.packetizer.com/voip/h323_vs_sip/ A kind of FUD. > Is SIP this much a weird protocol? No. It's of course totally weird, but much less weird than H.323. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
