Re: [Sip-implementors] Error in incoming req uri, what to do?
I'm kind of in the middle of the stack provider and the UA provider here... But I guess I should interpret your responses that in case of a sip uri with the # error, there is no specification that says that the UAS (B2BUA in this case) MUST send a sip response? // Andreas -Original Message- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: den 14 november 2007 22:43 To: Andreas Byström Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Error in incoming req uri, what to do? Andreas, The catchall response for this is 400. If the uri is syntactically invalid (which is the case if the user part contains #) then you are justified in returning that response. But IMO that is over zealous. If you are just a pass-through (a proxy or a B2BUA that doesn't care about this) then I think I would just ignore it. If you are the intended recipient, or are say a proxy authoritative for the domain of the URI that is expected to route based on the user part, and the user part isn't acceptable to you, then the 404 response seems appropriate to me. In that case it makes little difference if the user part has a syntactically invalid character, or has a value that syntactically valid but is semantically invalid to you. Paul Andreas Byström wrote: Thanks Paul, The actual case I'm talking about is a B2BUA which in this particular case acts as an AS. For some cases, the # is needed for the AS application (controlling the subscribers Call Forward settings by sending commands like *21*123456#) but other cases could be that the subscriber that placed the call just happened to press the # sign in the middle of a number. Anyway, for both cases I guess there should be a client (4xx) error triggered? My main question is really if there are some defined behavior somewhere that says that the B2BUA _must_ send a response for an incoming request with erroneous sip uri in request line, or if it is ok just to ignore it? It might be that the reqln uri is soo messed up that it will be hard to identify this as an SIP request... I dont know if a # could have such effect // Andreas -Original Message- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: den 14 november 2007 21:18 To: Andreas Byström Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Error in incoming req uri, what to do? The UA receiving this must (by definition) be the UAS. It *ought* to be the intended recipient of the request (leaving aside some B2BUAs which have different issues). As the intended recipient, the URI ought to be one it knows about. Since this one is malformed (and the UA probably wouldn't *intend* to support malformed ones) this URI must be something unknown to the UAS. In that case a good response is 404 Not Found. Paul Andreas Byström wrote: What should a UA do in case it receives an request with an malformed sipuri in the request line? For example if there is an incoming INVITE [EMAIL PROTECTED] sip/2.0 (ie the sender has not escaped the # character). I guess there would be good to respond with maybe 400 Bad Request or some other 4XX response, but I cant find something that supports this in the RFCs. Does anyone know if there is some specifications that defines what to do in a case with malformed uri in the requestline or is it up do the developer of the UAS to decide? If no answer at all the UAC will probably retransmit Regards, // Andreas ___ Andreas Byström Software Engineer Teligent AB Konsul Jonssons väg 17 P.O. Box 213 SE 14923 Nynäshamn mail: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] web: http://www.teligent.se/ www.teligent.se phone: +46 (0)8 4101 7221 mobile: +46 (0)733 1172 21 fax: +46 (0)8 520 193 36 ___ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Error in incoming req uri, what to do?
Attila, The '*' char shall not be escaped IMO, this is allowed by RFC 2396 in URI syntax. Have you references saying the '*' should be escaped? Andrea -- Message: 3 Date: Wed, 14 Nov 2007 15:11:41 -0600 From: Robert Sparks [EMAIL PROTECTED] Subject: Re: [Sip-implementors] UAS sending a CANCEL To: Jagan Mohan [EMAIL PROTECTED] Cc: sip-implementors@lists.cs.columbia.edu Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed You're looking for RFC3261 section 9. RjS On Nov 14, 2007, at 6:04 AM, Jagan Mohan wrote: Hi All, I have the following call flow: PSTN===Media Gateway-UAS Call flow is made from PSTN phone to UAS. Media --UAS Gateway INVITE 100 Trying 180 Ringing At this point, can UAS send a CANCEL to the media gateway? From the discussion in various mailing lists, I understand that UAS can not send a CANCEL request in this scenario. It can send a 4xx/6xx But, I could not find any RFC which talks about this. Could any one please provide info. on the RFC which talks about the above scenario? TIA, Jagan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Message: 4 Date: Wed, 14 Nov 2007 21:17:44 - From: Attila Sipos [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Error in incoming req uri, what to do? To: Andreas Bystr?m [EMAIL PROTECTED], sip-implementors@lists.cs.columbia.edu Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 I seem to remember some discussion about the # and # character a long time ago. You could respond with 400 Bad Request but I think it would be best if you just treated it as if the # had been escaped. I know it's not strictly compliant but: 1. I don't think it does any harm - check the grammar for yourself but I don't think there are any parser clashes 2. you will improve your interop - I have seen many UAs that haven't escaped these characters - so it's best if you try to accept them. One more thing - always escape the # and * if you use it in the user part of a URI. People over-use the saying be liberal with what you accept and strict with what you send - I don't always agree with it because it's the road to chaos but in this case I don't think it's harmful. Regards, Attila ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Error in incoming req uri, what to do?
From: =?iso-8859-1?Q?Andreas_Bystr=F6m?= [EMAIL PROTECTED] I'm kind of in the middle of the stack provider and the UA provider here... But I guess I should interpret your responses that in case of a sip uri with the # error, there is no specification that says that the UAS (B2BUA in this case) MUST send a sip response? Clearly, the UA should send a response, either success or failure, depending on the strategy you choose. Otherwise the upstream agent will keep sending you the request, and then eventually time-out, which from the point of view of the overall SIP system is the worst failure mode. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Error in incoming req uri, what to do?
I agree with Dale, especially about not forwarding a malformed URI. OTOH, I don't believe that forwarding nodes are *obligated* to verify the validity of everything in a message they forward. So for instance if a node notices that the domain is not its own, and so forwards based on the domain name it might just not validate the user part at all. Or if it forwards based on the Route header it may barely notice the R-URI. So, I think 400 is certainly acceptable in this case, but other error responses are also acceptable. Thanks, Paul [EMAIL PROTECTED] wrote: From: Paul Kyzivat [EMAIL PROTECTED] The UA receiving this must (by definition) be the UAS. It *ought* to be the intended recipient of the request (leaving aside some B2BUAs which have different issues). As the intended recipient, the URI ought to be one it knows about. Since this one is malformed (and the UA probably wouldn't *intend* to support malformed ones) this URI must be something unknown to the UAS. In that case a good response is 404 Not Found. I would say that 400 is acceptable also, because the UA may not be even able to parse the incoming message enough to decide what precisely it didn't like about. If the UA is one that never forwards messages, it seems plausible that it might take a liberal interpretation of an un-escaped character that should be escaped but otherwise has no interpretation. If the UA is considering sending the message on, I would argue strongly that it should reject the message, because it can't forward the message in a strictly compliant way without making guesses as to what the sender meant, and it does not have the implicit information if I received it, it must have been intended for me. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Error in incoming req uri, what to do?
Andreas, So this stack provider drops syntactically incorrect requests rather than generating an error response. And you would like some reference to 3261 that says a response should be sent in this case. IMO a response should always be sent unless the request is malformed in a way that makes it impossible to send a syntactically correct response. So, if the From, To, or Via were malformed then there is justification for not sending a response, but since the R-URI doesn't appear in the response that isn't an issue here. (But if the same value is in the To, then maybe it does apply.) But of course servers are permitted to drop requests for arbitrary reasons, such as being overloaded. So I don't think there is anything that says there is a *requirement* to respond to this request. Paul Andreas Byström wrote: I also agree that for this specific case I dont want to forward the request since that means that the B2BUA application needs to send out a request that it know is wrong but cant be 100% sure that it should escape the # sign to make it correct. The thing is that I'm building the B2BUA application on top of a SIP stack (from another supplier). Now our customer has some UAs that does not escape #, and our customer agrees that it is wrong and that the UA should be updated (and it will in time). However, the stack I'm using does not send any response (no response at all) and does not even trigger my application (so I have no real option to try to forward the message) when it gets an INVITE with # . The customer wants the B2BUA to send an 4xx response, while the stack provider says it does not consider it to be needed. I do agree with the customer in this case but I really need to point out to the provider that look at rfc3261, page X section Y to really convince them that they MUST send a response. Even though I think it is obvious that the stack should send a response (or send it up to the application so that I can reject it with 4xx myself), I have tried to find such a statement in the RFC but failed. Sending no answer at all means that the UA will retransmit until timeout and as you already have said that is not a good solution. Hope that you can help me out on this :) // Andreas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: den 15 november 2007 15:30 To: [EMAIL PROTECTED] Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Error in incoming req uri, what to do? I agree with Dale, especially about not forwarding a malformed URI. OTOH, I don't believe that forwarding nodes are *obligated* to verify the validity of everything in a message they forward. So for instance if a node notices that the domain is not its own, and so forwards based on the domain name it might just not validate the user part at all. Or if it forwards based on the Route header it may barely notice the R-URI. So, I think 400 is certainly acceptable in this case, but other error responses are also acceptable. Thanks, Paul [EMAIL PROTECTED] wrote: From: Paul Kyzivat [EMAIL PROTECTED] The UA receiving this must (by definition) be the UAS. It *ought* to be the intended recipient of the request (leaving aside some B2BUAs which have different issues). As the intended recipient, the URI ought to be one it knows about. Since this one is malformed (and the UA probably wouldn't *intend* to support malformed ones) this URI must be something unknown to the UAS. In that case a good response is 404 Not Found. I would say that 400 is acceptable also, because the UA may not be even able to parse the incoming message enough to decide what precisely it didn't like about. If the UA is one that never forwards messages, it seems plausible that it might take a liberal interpretation of an un-escaped character that should be escaped but otherwise has no interpretation. If the UA is considering sending the message on, I would argue strongly that it should reject the message, because it can't forward the message in a strictly compliant way without making guesses as to what the sender meant, and it does not have the implicit information if I received it, it must have been intended for me. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Error in incoming req uri, what to do?
I also agree that for this specific case I dont want to forward the request since that means that the B2BUA application needs to send out a request that it know is wrong but cant be 100% sure that it should escape the # sign to make it correct. The thing is that I'm building the B2BUA application on top of a SIP stack (from another supplier). Now our customer has some UAs that does not escape #, and our customer agrees that it is wrong and that the UA should be updated (and it will in time). However, the stack I'm using does not send any response (no response at all) and does not even trigger my application (so I have no real option to try to forward the message) when it gets an INVITE with # . The customer wants the B2BUA to send an 4xx response, while the stack provider says it does not consider it to be needed. I do agree with the customer in this case but I really need to point out to the provider that look at rfc3261, page X section Y to really convince them that they MUST send a response. Even though I think it is obvious that the stack should send a response (or send it up to the application so that I can reject it with 4xx myself), I have tried to find such a statement in the RFC but failed. Sending no answer at all means that the UA will retransmit until timeout and as you already have said that is not a good solution. Hope that you can help me out on this :) // Andreas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: den 15 november 2007 15:30 To: [EMAIL PROTECTED] Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Error in incoming req uri, what to do? I agree with Dale, especially about not forwarding a malformed URI. OTOH, I don't believe that forwarding nodes are *obligated* to verify the validity of everything in a message they forward. So for instance if a node notices that the domain is not its own, and so forwards based on the domain name it might just not validate the user part at all. Or if it forwards based on the Route header it may barely notice the R-URI. So, I think 400 is certainly acceptable in this case, but other error responses are also acceptable. Thanks, Paul [EMAIL PROTECTED] wrote: From: Paul Kyzivat [EMAIL PROTECTED] The UA receiving this must (by definition) be the UAS. It *ought* to be the intended recipient of the request (leaving aside some B2BUAs which have different issues). As the intended recipient, the URI ought to be one it knows about. Since this one is malformed (and the UA probably wouldn't *intend* to support malformed ones) this URI must be something unknown to the UAS. In that case a good response is 404 Not Found. I would say that 400 is acceptable also, because the UA may not be even able to parse the incoming message enough to decide what precisely it didn't like about. If the UA is one that never forwards messages, it seems plausible that it might take a liberal interpretation of an un-escaped character that should be escaped but otherwise has no interpretation. If the UA is considering sending the message on, I would argue strongly that it should reject the message, because it can't forward the message in a strictly compliant way without making guesses as to what the sender meant, and it does not have the implicit information if I received it, it must have been intended for me. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Error in incoming req uri, what to do?
Attila Sipos wrote: I seem to remember some discussion about the # and # character a long time ago. You could respond with 400 Bad Request but I think it would be best if you just treated it as if the # had been escaped. I know it's not strictly compliant but: 1. I don't think it does any harm - check the grammar for yourself but I don't think there are any parser clashes 2. you will improve your interop - I have seen many UAs that haven't escaped these characters - so it's best if you try to accept them. One more thing - always escape the # and * if you use it in the user part of a URI. People over-use the saying be liberal with what you accept and strict with what you send - I don't always agree with it because it's the road to chaos but in this case I don't think it's harmful. Wow! Attila and I agree on something!!! The be liberal part is only useful when there is only *one* liberal interpretation that everyone who is liberal follows. When people are liberal in inconsistent ways it does lead to chaos. The catch of course is that if you actually specify the particular liberal behavior that everyone should follow then it is no longer liberal - its conservative because it is then part of the spec. So it works when the liberal interpretation is obvious. That is the case here I think. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Error in incoming req uri, what to do?
Hi, In my opinion, UAS should send one of following ...400, 416. thanks, Vipul Rastogi Engineer, Business Management Team Telecommunication Network Business Samsung Electronics CO, LTD Suwon P.O.BOX 105, 416 Korea 442-600 MO 010-9530-0354 - Original Message - From: Andreas Bystr?m [EMAIL PROTECTED] To: sip-implementors@lists.cs.columbia.edu Sent: Thursday, November 15, 2007 3:41 AM Subject: [Sip-implementors] Error in incoming req uri, what to do? What should a UA do in case it receives an request with an malformed sipuri in the request line? For example if there is an incoming INVITE [EMAIL PROTECTED] sip/2.0 (ie the sender has not escaped the # character). I guess there would be good to respond with maybe 400 Bad Request or some other 4XX response, but I cant find something that supports this in the RFCs. Does anyone know if there is some specifications that defines what to do in a case with malformed uri in the requestline or is it up do the developer of the UAS to decide? If no answer at all the UAC will probably retransmit. Regards, // Andreas ___ Andreas Bystr?m Software Engineer Teligent AB Konsul Jonssons v?g 17 P.O. Box 213 SE 14923 Nyn?shamn mail: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] web: http://www.teligent.se/ www.teligent.se phone: +46 (0)8 4101 7221 mobile: +46 (0)733 1172 21 fax: +46 (0)8 520 193 36 ___ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
