Hello, I have the scenario where the call is coming to SBC from my source UA and then I am forwarding the same call to redirect server to route the call.
Here is the scenario. 1) Call come to my source UA and then I forwarded the call to redirect server with below REQUEST uri. Request-Line: INVITE sip:17139229...@208.70.157.43<sip%3a17139229...@208.70.157.43>;user=phone SIP/2.0 Request-URI: sip:17139229...@208.70.157.43 <sip%3a17139229...@208.70.157.43> ;user=phone To: sip:17139229...@208.70.157.43 <sip%3a17139229...@208.70.157.43> ;user=phone From: "Joe Gonzales" <sip:2816524...@64.124.207.220<sip%3a2816524...@64.124.207.220> ;user=phone>;tag=3477742912-272141 Contact: <sip:2816524...@64.124.207.220:5060;user=phone;tgrp=100054CUST> 2) Now from here my *redirect server* replied me with below uri in TO & FROM, but will multiple CONTACT header and on which I have the first CONTACT user part is with “1” and the others all are same but carry the “1” with rest of the user part. IP/2.0 300 Redirect To: <sip:17139229...@208.70.157.43 <sip%3a17139229...@208.70.157.43> ;user=phone>;tag=a667a4b9fa6bfa35b From: "Joe Gonzales" <sip:2816524...@64.124.207.220<sip%3a2816524...@64.124.207.220> ;user=phone>;tag=3477742912-272141 Via: SIP/2.0/UDP 64.124.207.220:5060 ;branch=z9hG4bKb96ce5413fe01d59101005f4ae3881c6 Contact: <sip:7139229...@64.124.207.220 <sip%3a7139229...@64.124.207.220> ;dtg=202583VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202393VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202562VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202405VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202163VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202203VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202525VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=201030VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202330VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202206VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=202329VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=201906VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=201908VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=201907VEND>, sip:17139229...@64.124.207.220 <sip%3a17139229...@64.124.207.220> ;dtg=201905VEND> 3)However after sending the ACK my server again sent the another invite to my vendor with below REQUEST URI with “1” whereas in first CONTACT header from redirect was not carrying the “1” Contact: sip:7139229...@64.124.207.220 <sip%3a7139229...@64.124.207.220> ;dtg=202583VEND. Request-Line: INVITE sip:17139229...@64.245.120.88<sip%3a17139229...@64.245.120.88>SIP/2.0 Request-URI: sip:17139229...@64.245.120.88 <sip%3a17139229...@64.245.120.88> Whereby in TO header(of the same INVITE) I do not have the “1” in user part as below. To: sip:7139229...@64.245.120.88 <sip%3a7139229...@64.245.120.88> Contact: sip:64.124.207.220:5060;tgrp=100054CUST And because of this my vendor is sending immediate 502 REJECTED. Status-Line: SIP/2.0 502 Rejected - Called number is not NATNUM Could anyone please help me on this, whether it is a correct or not,because as far as I know he user part of the Request uri would be checked first. User part of the Request uri is valid but the To header is different from Request uri so now a validation for the User part of the To header will be performed and if the user part is found to be invalid then a 404 (Not Found) response should sent back. Thanks, Nitin Kapoor
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use sip-implement...@cs.columbia.edu for questions on how to develop a SIP implementation. Use dispa...@ietf.org for new developments on the application of sip. Use sipc...@ietf.org for issues related to maintenance of the core SIP specifications.
