Hi Abhinesh, Thanks for the solution. The solution is pretty good. But this works only for the calls originating and terminating in the same network. If the calls are originated from other networks or terminated in other networks (belonging to some other operator), then SIPB2B should have some intellegence to recognise these calls.
Please check my ideas in this case, 1) If SIPB2B receives a call (from UAC or GateWay), if the IP/DOMAIN of FROM header of the call dosen't matches the configured addresses then it will be treated as an MT (Inbound) call. 2) If the request uri of the received call dosen't matches the configured addresses then it will be treated as MO call. 3) If both IP/Domain of FROM header and that of Request Uri are matched with the configured addresses then we need to charge it twice. Now we need to implement a similar solution of routing the call to second SIPB2B or routing it to same SIPB2B again with some indication (like route header as you suggested), that the call is charged for MO and need to be charged for MT to avoid loop. I am not sure whether I am thinking in a right way or not, I solicit your guidance. Thanks, Kiran. On Wed, Oct 12, 2011 at 12:45 PM, Abhinesh Patil < [email protected]> wrote: > Hi Kiran, > > Can you explain the mechanism of forwarding Call to UAS from SIPB2B > i.e. will the call come to SIPB2B two times as shown below: > 1. From UAC to 1st SIPB2B (catering to UAC) in case of Mobile > Originated case. > > 2. From 1st SIPB2B to 2nd SIPB2B (catering to UAS). (This is mobile > terminated case. Case may be that the same SIPB2B is catering to UAC > and UAS). > > 3. From 2nd SIPB2B to UAS. > > If you are using same mechanism as mentioned above, you can use user > part of "route" header used by UAC while forwarding request to 1st > SIPB2B i.e. you can configure route header like "MO@SIPB2B_1.com". In this > case 1st SIPB2B can identify the request as MO case by inspecting > top > "route" header. > > When request is forwarded by 1st SIPB2B, it can insert another route > header like "MT@SIPB2B_2.com" (user part MT) in request which can be > used > by 2nd SIPB2B to identify request as MT case. If the same SIPB2B is > catering > to UAC and UAS, SIPB2B can route the request to itself after inserting the > required "route" header. > > Hope This solves your problem. > > Thanks > Abhinesh Patil > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of kiran > kumar > Sent: Wednesday, October 12, 2011 12:19 AM > To: sip-implementors > Subject: [Sip-implementors] How to distinguish between MO and MT calls in > SIP networks > > Hi all, > > I am developing a SIPB2B which acts as a session controller. > No registration mechanism is implemented in it. > It will directly receives Invite from UAC and forwards it to UAS after > successful billing authentication. > > Can any one help me, how could I distinguish between MO and MT calls (In > pure SIP networks). > Is there any SIP header to determine the call type. > > Thanks, > Kiran. > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
